Live › vulnerability › CVE-2026-116176
Go to dashboardvLLM from 0.9.2 before 0.24.0 lets an API caller embed a decode address in the X-Request-Id header, forcing a P2pNcclConnector prefill worker to connect to an attacker-chosen host. An attacker can leak the NCCL unique_id and KV-cache tensors, or block the worker.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-25 14:41 UTC. All times on this page are UTC.
Teams running vLLM from 0.9.2 up to but not including 0.24.0 that expose its API to callers who can send request headers. The sources tie the flaw to the P2pNcclConnector prefill worker path, so deployments that do not use that connector are likely less exposed, but the sources do not confirm this. Teams on 0.24.0 or later can skip it.
No product ranges from the sources yet.
pip show vllm or python -c "import vllm; print(vllm.__version__)"0.24.0 or laterEach row is the first time that source carried this signal. The analyst’s rows are its own findings.
vLLM from 0.9.2 before 0.24.0 contains a server-side request forgery vulnerability that allows API callers to force outbound connections by embedding a decode address in the X-Request-Id header. Attackers can make a P2pNcclConnector prefill worker ZMQ-connect to an attacker host, leaking the NCCL unique_id and KV-cache tensors or blocking the worker.
This page as .md · .json · in your agent: get_signal("CVE-2026-116176")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.