Advisory · CVE-2026-116176
vLLM X-Request-Id header can drive P2pNcclConnector to an attacker host and leak KV-cache data
vLLM from 0.9.2 before 0.24.0, when running with P2pNcclConnector, copies the X-Request-Id header into the request ID and extracts a decode address from it with no allow-list, so an API caller can force a prefill worker to connect to an attacker host and send it the NCCL unique_id and KV-cache tensors. CVSS 3.1 8.2.
- Vendor
- vLLM
- Product
- vLLM
- Identifier / CWE
- CVE-2026-116176
CWE-918 - Action timing
- Immediate
Explain it like I’m five
vLLM treats a tracking label on each request as trusted directions, so an attacker can write a forwarding address on the label and have a worker deliver its working memory, including prompt text, to that address.
- 01Connector is enabled
A deployment runs a prefill worker with P2pNcclConnector configured as the KV-transfer connector.
- 02Crafted header sent
An API caller sends a completions request whose X-Request-Id header embeds a decode address naming an attacker host.
- 03Address is trusted
vLLM copies the header into the request ID and the connector extracts the host and port with no allow-list or scheme check.
- 04Worker connects out
The prefill worker opens a ZMQ connection to the attacker host and shares the NCCL communicator unique_id over it.
- 05KV-cache is sent
The worker sends KV-cache tensors for the targeted request over that channel, exposing prompt text and cached hidden states, and an unresponsive host can block the worker.
What happened
The vLLM project disclosed CVE-2026-116176 in its GitHub security advisory. OpenAIServing copies the HTTP X-Request-Id header verbatim into the request ID used throughout the engine, and P2pNcclConnector extracts an arbitrary host and port from that value with a permissive pattern and no allow-list or scheme check. An API caller can embed a routing token in the header to force a prefill worker running with P2pNcclConnector to connect outbound to an attacker-controlled host, share the NCCL communicator unique_id over that channel, and ultimately send the KV-cache tensors of the targeted request to the attacker.
The vendor advisory scopes the flaw to vLLM from 0.9.2 before 0.24.0 when using P2pNcclConnector, names 0.24.0 as the patched version, and states the fix removed the affected connector and its registration. It also states the preconditions plainly: the connector must be configured as the KV producer, and the caller needs no privileges beyond a valid API key, or no key at all where the server runs without one. The advisory notes the exposed KV-cache includes prompt text and prefix-cached hidden states, and that a blocking connection attempt against an unresponsive host is also a denial-of-service vector against the prefill worker.
What to do
- Inventory vLLM serving deployments and identify any that configure P2pNcclConnector for KV transfer, especially multi-node prefill and decode setups.
- Upgrade affected deployments to vLLM 0.24.0 or later using the project release guidance.
- Until upgraded, disable P2pNcclConnector or restrict the serving API to trusted callers only, and strip client-supplied X-Request-Id headers at any proxy in front of vLLM.
- Hunt for request IDs containing decode-address patterns, and for outbound ZMQ or NCCL connections from prefill workers to hosts outside the serving cluster.
- Treat prompt data processed by an exposed worker as potentially disclosed, and review which tenants and workloads shared that worker.
Management note
A request-tracking header became a routing instruction for the inference fabric. Clusters that enabled peer-to-peer KV transfer for performance should patch first and then ask why any client header was ever allowed to name a worker destination.