CVE-2026-116176: vLLM fixes an SSRF that can leak KV-cache tensors, plus three ways to crash a shared server
Four vLLM CVEs were published on 25 October 2026. The worst lets an API caller put an attacker's host in the X-Request-Id header so a P2pNcclConnector prefill worker connects out and sends that request's KV-cache tensors to it. The other three let a client crash or OOM-kill a shared vLLM server. Upgrading to vLLM 0.31.0 covers all four.
What it is
CVE-2026-116176 (GHSA-vfp2-c8pq-v6h6, SSRF): vLLM copies the X-Request-Id header verbatim into the internal request id, and P2pNcclConnector pulls a host:port out of it with no allow-list. A caller can make a prefill worker ZMQ-connect to an attacker host, share the NCCL unique_id and send the request's KV-cache tensors there, or block the worker. Only deployments running P2pNcclConnector as a kv_producer are affected; vLLM 0.9.2 up to 0.24.0.
CVE-2026-116180 (GHSA-rhcx-5729-88vg, cross-tenant crash): LogprobsTensors.empty_cpu() leaves a tensor uninitialized, and positions a KV connector reports as already computed are never written. One request with prompt_logprobs (or echo plus logprobs) against a connector-cached prefix makes tokenizer decode raise OverflowError, which kills EngineCore and drops every co-tenant request. Affects V1 engines using connectors such as LMCacheConnectorV1 or NixlConnector; vLLM 0.8.5 up to 0.31.0.
CVE-2026-116179 (GHSA-4m6g-h9mv-wqjc, memory exhaustion): a client could override num_frames through media_io_kwargs, set it to -1 and make the API frontend decode every frame of a large inline video/jpeg payload, exhausting memory. vLLM 0.18.0 up to 0.31.0. The fix rejects per-request media_io_kwargs unless the server is started with --trust-request-mm-kwargs.
CVE-2026-116177 (GHSA-mm38-5g96-7j6x, decompression bomb): the Nemotron-VL processors set Pillow's Image.MAX_IMAGE_PIXELS to None for the whole process, so an unauthenticated caller of /v1/chat/completions can send a decompression-bomb image and OOM-kill the worker. NVD lists vLLM 0.10.2 up to 0.25.0; the GitHub advisory says it was confirmed on 0.8.5. The fix adds a pixel limit configurable with VLLM_MAX_IMAGE_PIXELS.
How to check
- Affected: vllm (PyPI) before 0.31.0 for the two crash bugs, before 0.24.0 for the SSRF and before 0.25.0 for the decompression bomb (version ranges above).
- You are most exposed if several users or tenants share one vLLM server, if you use disaggregated prefill with a KV connector (P2pNcclConnector, LMCache, Nixl), or if you serve multimodal (video or Nemotron-VL) models.
How to fix
- Upgrade vllm to 0.31.0 or later.
- Until then, don't let untrusted clients set X-Request-Id or media_io_kwargs (strip them at your proxy), keep API keys on, and don't share one engine between tenants you don't trust.
pip show vllm | grep -i versionSources
- criticalCVE-2026-22778: vLLM has RCE In Video Processing
- criticalCVE-2025-47277: vLLM Allows Remote Code Execution via PyNcclPipe Communication Service
- criticalCVE-2025-32444: vLLM Vulnerable to Remote Code Execution via Mooncake Integration
- highCVE-2026-115912: vLLM 0.32.0 fixes a forged shared-memory handle that reaches pickle.loads, EPS images that can reach Ghostscript, and five ways to stall or crash the server