vLLM accepted a client request ID as a trusted KV transfer destination

A request identifier should correlate logs, not choose where inference state leaves a server. The affected connector encoded a remote decode address in the request ID; when the HTTP client could supply that string, it steered a prefill worker to an attacker-controlled network peer. primary evidence documents both the outbound connection and cache-transfer path, so this is an execution boundary failure in AI inference infrastructure.

Only deployments using the listed P2pNcclConnector and producer role were affected. The advisory does not establish widespread theft of model prompts; an unresponsive receiver can also block a worker.

Remove the connector or update beyond the vulnerable range; never allow client metadata to select private transfer peers. Network allowlisting alone is weaker than an operator-authenticated peer identity.

The attack chain is not generic HTTP SSRF. vLLM copied the untrusted X-Request-Id into an engine request ID; P2pNcclConnector parsed a decode address from that string and established a ZMQ socket and NCCL communicator to the supplied peer. The advisory traces KV tensor transmission and a blocking-connect denial-of-service condition. The vulnerable range was 0.9.2 through versions below 0.24.0, only when the P2pNcclConnector producer mode was configured; 0.24.0 removed the connector. This does not prove all inference servers leaked raw prompts, nor does a general request ID become dangerous absent that specialized parse path.