vLLM CVE-2026-116176

Exploitation requires the target prefill worker to be launched with '--kv-transfer-config '{"kv_connector":"P2pNcclConnector","kv_role":"kv_producer",...}'' - the vulnerable V1 P2pNcclConnector must be active; the attack has no effect on default vLLM deployments that do not use this connector. The attacker needs only to send a /v1/completions or /v1/chat/completions request carrying an X-Request-Id header matching the regex '___decode_addr_(.*):(\d+)', plus a valid API key when '--api-key' is set (no key is needed if '--api-key' is unset). Limiting factors: the non-default disaggregated-serving configuration, network reachability to the prefill worker, and the API-key requirement where one is configured; no user interaction is required.

Multiple signals converge on this being a genuine but conditional priority. The input CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) describes a network-reachable, low-complexity SSRF with high confidentiality impact (VC:H) and low availability impact (VA:L), scored 8.8, and the vuln.today decision label is 'this_week' - not 'act_now' or 'emergency'. There is no EPSS score provided, no CISA KEV listing, and no PoC or exploit reference in the supplied data, so exploitation status is 'no public exploit identified at time of analysis'. The key tension is between the PR:N (unauthenticated) metric and the advisory text: exploitation is only possible against a prefill worker explicitly started with '--kv-transfer-config' selecting P2pNcclConnector in kv_producer role - a non-default, specialized disaggregated-serving configuration - and the caller needs a valid API key unless '--api-key' is unset. So the raw CVSS network/unauth profile overstates the exposed population: the real risk is concentrated in the subset of vLLM deployments running the P2pNcclConnector prefill path, where the risk is high (full KV-cache/prompt exfiltration plus a worker DoS via a blocking ncclCommInitRank). For operators NOT using that connector, effective risk is negligible. Treat as a this-week patch item for affected disaggregated-serving deployments, lower priority elsewhere.

An attacker who can reach a vLLM prefill worker configured with P2pNcclConnector sends a normal /v1/completions or /v1/chat/completions request but sets the X-Request-Id header to a value embedding a routing token like '___decode_addr_<attacker-ip>:<port>'. vLLM copies the header verbatim into the request_id, parse_request_id extracts the attacker's host:port with no allow-list, and the worker opens an outbound ZMQ connection and NCCL bootstrap to the attacker, leaking the NCCL unique_id and then ncclSend-ing the request's KV-cache tensors (prompt text and prefix-cached hidden states). No public exploit is identified at time of analysis, though the GHSA advisory documents exact code paths and line numbers.