GPU VulnDB

Database/AI/ML frameworks & serving

vLLM: attacker-supplied X-Request-Id makes a prefill worker ZMQ-connect out, leaking NCCL id and KV cache

CVSS 8.8CVE-2026-116176AI/ML frameworks & servingcurated

Impact

A caller of the inference API controls where a disaggregated-prefill worker opens an outbound ZMQ connection by putting a decode address in the X-Request-Id header. The worker then hands the attacker host the NCCL unique_id and KV-cache tensors for in-flight requests, so prompt and generated content belonging to other callers leaks off the node, and the NCCL id is enough to join the collective the serving group uses. The same primitive points the worker at a host that never answers, parking the prefill stage and stalling the serving group. On a shared GPU fleet this is a cross-tenant disclosure path that leaves the GPUs resident and busy, and it reaches outbound from inside the cluster network, so egress-restricted nodes are only partly protected.

Who can reach it

Anyone who can send an HTTP request to the vLLM API server, including through a gateway that forwards client headers. No authentication is needed beyond whatever fronts the endpoint, and only deployments using the P2pNcclConnector for prefill/decode disaggregation are affected.

What to do

Upgrade vLLM to 0.24.0 or later and restart the API server and every prefill/decode worker - a rolling restart per replica, no node reboot. Until then, strip or overwrite X-Request-Id at the ingress in front of vLLM, and confirm the serving namespace cannot open arbitrary outbound TCP connections.

References

Related entries

All AI/ML frameworks & serving entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.