What happened
vLLM's OpenAIServing copies the HTTP X-Request-Id header verbatim into the request_id, and P2pNcclConnector.parse_request_id extracts an arbitrary host:port from it via a permissive regex with no allow-list, scheme check, or IP-literal block. An API caller can embed a decode address in the header to force a prefill worker running the connector to ZMQ-connect outbound to an attacker host, share the NCCL communicator unique_id, and then ncclSend the targeted request's KV-cache to the attacker.
Why it matters
Using only an HTTP header, a caller that can reach a prefill worker (valid API key, or no key if --api-key is unset) can exfiltrate the full KV-cache of any request that worker processes—prompt text and prefix-cached hidden states—and can block the worker on an unresponsive host, a denial-of-service vector. CVE-2026-116176, CVSS 8.2, CWE-918.
Attack vector
Craft a /v1/completions or /v1/chat/completions request with an X-Request-Id containing an attacker-controlled host:port; the prefill worker connects outbound and leaks KV-cache tensors.
Affected systems
vLLM >= 0.9.2, < 0.24.0 when running P2pNcclConnector (requires --kv-transfer-config with P2pNcclConnector).
Mitigation
Upgrade to vLLM 0.24.0 (PR #44854 removed the affected connector); also strip/replace X-Request-Id with a random UUID while P2pNcclConnector is active and validate the connector's remote_address against an operator-configured CIDR allow-list.