vLLM's P2pNcclConnector leaks KV-cache tensors when callers plant a host in X-Request-Id

A tracing header is a strange place to put a decode address. vLLM treated it as routing instructions anyway.

On 25 October 2026, CVE-2026-116176 and three companion availability CVEs were published against vLLM's KV-transfer and multimodal edges. The headline bug turns X-Request-Id into SSRF that can ship KV-cache tensors off-box.

X-Request-Id becomes a ZMQ peer, then NCCL sends the cache

GHSA-vfp2-c8pq-v6h6 / CVE-2026-116176 (CVSS 3.1 8.2) affects vLLM from 0.9.2 before 0.24.0 when P2pNcclConnector runs as kv_producer. OpenAIServing._base_request_id copied the HTTP X-Request-Id header verbatim into the engine request_id. P2pNcclConnector.parse_request_id then applied a permissive regex ___decode_addr_(.*):(\d+) with no allow-list or scheme check.

From there the prefill worker's create_connect opened tcp://{remote_address} over ZMQ, shipped the NCCL communicator unique_id, and send_sync used ncclSend to transmit that request's KV-cache tensors (prompt text and prefix-cached hidden states) to the attacker-controlled peer. An unresponsive peer also blocked ncclCommInitRank, denying service on the prefill worker. No privilege beyond API access is required; if --api-key is unset, that bar is empty. PR #44854 removed the affected connector and its registration in 0.24.0.

Three companions published the same day widen shared-server risk. CVE-2026-116180 (GHSA-rhcx-5729-88vg) covers uninitialized logprobs tensors plus connector-reported cached positions: one tenant's prompt_logprobs request can OverflowError the EngineCore and drop co-tenants on V1 engines with connectors such as LMCacheConnectorV1 or NixlConnector. That path is fixed by 0.31.0.

CVE-2026-116179 (GHSA-4m6g-h9mv-wqjc) lets clients override num_frames through media_io_kwargs to -1 and force full decode of large inline video, exhausting memory. The NVD range is 0.18.0 before 0.31.0; the fix rejects per-request kwargs unless --trust-request-mm-kwargs is set.

CVE-2026-116177 (GHSA-mm38-5g96-7j6x) covers Nemotron-VL processors that set Image.MAX_IMAGE_PIXELS = None process-wide, so a decompression-bomb image on /v1/chat/completions can OOM the worker (NVD range 0.10.2 before 0.25.0). Vibevulns recommends 0.31.0 to cover the set.

Disaggregated prefill made request ids into trust boundaries

KV-transfer connectors exist so prefill and decode can split across machines. That design only works if the peer address comes from operator config rather than from a client tracing header. CVE-2026-116176 is the concrete failure of that assumption. It is a new fact pattern versus the published vLLM 0.32 SHM-pickle and Ghostscript advisories: those concerned multimodal cache handles and image decoder dispatch; this concerns P2pNccl routing and a CVE wave dated 25 October for bugs fixed earlier in the 0.24-0.31 line.

Apache serving stack; maturity is version-gate by connector

vLLM remains Apache-2.0. Activity: connector removal in 0.24.0 (June timeframe per advisory history); companion fixes through 0.31.0; CVE records published 25 October 2026. Maturity: any public or multi-tenant prefill worker that still advertises P2pNcclConnector below 0.24.0 is overdue. Shared engines below 0.31.0 remain on the companion DoS list even if P2P NCCL is gone.

Land on 0.31.0+, strip client X-Request-Id at the proxy

Upgrade vLLM to 0.31.0 or later for the combined CVE set, and confirm P2pNcclConnector is absent from kv-transfer-config. Until then, strip or rewrite X-Request-Id and media_io_kwargs at the reverse proxy, keep API keys on, and avoid sharing one EngineCore across mutually untrusted tenants. Teams already past 0.32 for the SHM/Ghostscript wave still need to verify they are not carrying an older prefill image that retained P2P NCCL.

Header allow-through, multi-tenant engines, and old prefill pins

Proxies that forward client tracing headers verbatim recreate the SSRF input even behind "authenticated" gateways. Multi-tenant platforms that expose prompt_logprobs on connector-cached prefixes inherit the EngineCore kill. Pinning a "stable" 0.23.x prefill image for performance reasons keeps the removed connector's blast radius alive after decode nodes move on.

Treat request ids as untrusted on KV-transfer paths

Inventory every vLLM prefill worker for P2pNcclConnector, bump the fleet to 0.31.0+, and add a proxy test that a planted decode address in X-Request-Id never leaves your VPC. The open Monday question is how many disaggregated graphs still trust client request ids as routing tokens.