vLLM's 10 new CVEs: SSRF, engine crashes, fixes by version

If you run vLLM and it is reachable by anyone you do not fully trust, check your version today. GitHub’s advisory database added ten records for vLLM on October 25, each with a CVE number, and two more on October 23. We read the vLLM project’s own advisories, GitHub’s records, and the 0.31.0 and 0.32.0 release notes. This article covers what the flaws are, which release fixes each, who is actually exposed, what you can do before upgrading, and what we could not confirm. We ran none of this, and we leave out the technical detail of how to trigger any of it.

What was published, and when?

Ten CVE records on October 25 for advisories that were already public. The records, marked unreviewed by GitHub, were added at 15:32 UTC and carry CVE-2026-116172 through CVE-2026-116181. Each points to a vLLM advisory dated October 9. Two reviewed records, CVE-2026-114050 and CVE-2026-114055, were added on October 23 for advisories dated October 6. The vLLM advisory pages we opened list “No known CVE” and name the same GitHub account as publisher and coordinator, with outside reporters credited per advisory, for example mschwarzl for the SSRF, mcgrof for the logprobs crash, Chedrian07 for the multimodal kwargs issue and tonghuaroot for the video one. So the news is the CVE numbers and the scanner coverage they bring, more than new disclosures.

Which release fixes what?

Grouped by the first release that fixes each. Ratings are GitHub’s records unless marked otherwise.

• 0.24.0 (June 29):
  • SSRF through the request-ID header (CVE-2026-116176, 8.2; High on vLLM’s page): affects 0.9.2 up to 0.24.0 when a prefill worker runs P2pNcclConnector.
  • Three Rust gRPC frontend flaws (CVE-2026-116172, -116173, -116174, 5.9 each): crafted Generate or GenerateStream requests can terminate the engine core. Affects 0.22.0 up to 0.24.0.
  • Audio decoding that skips the decompression-bomb limit (CVE-2026-116175, 6.5): small compressed audio can exhaust server memory. Affects 0.19.0 up to 0.24.0.
• 0.25.0: Nemotron-VL image processors switch off Pillow’s decompression-bomb guard for the whole process (CVE-2026-116177, 7.5). The affected range differs: vLLM’s page says up to 0.8.5, GitHub’s record says 0.10.2 up to 0.25.0.
• 0.29.0: out-of-vocabulary stop_token_ids can crash the engine or write outside the logits buffer (CVE-2026-116181, 6.5). Affects 0.20.1 up to 0.29.0.
• 0.30.0: inconsistent multimodal metadata on the disaggregated /inference/v1/generate endpoint crashes the engine (CVE-2026-116178, 5.9). Affects 0.20.0 up to 0.30.0.
• 0.31.0:
  • Video frame-count cap bypass (CVE-2026-116179, 7.5): a large inline video can exhaust memory in the API frontend. Affects 0.18.0 up to 0.31.0.
  • Cross-tenant crash from uninitialized logprobs memory (CVE-2026-116180, 7.7): needs a KV connector.
  • Forged multimodal UUIDs desynchronizing processor caches (CVE-2026-114050, 6.5): crashes the whole engine. Affects versions before 0.31.0.
  • Unvalidated per-request mm_processor_kwargs (CVE-2026-114055, 7.5): can exhaust resources. Affects 0.7.3 up to 0.31.0.
• 0.32.0 (October 18): two advisories dated October 20, an out-of-vocabulary prompt token ID that triggers a CUDA assert and a ZeroMQ socket exhaustion in the P2P offloading path (0.26.0 only). We found no CVE for either.

Who is actually exposed?

Anyone serving vLLM to clients they do not control, and especially shared deployments. Most of these flaws end in the engine crashing, and the logprobs advisory notes that a crash drops every in-flight request, not only the sender’s. Several need a particular setup, though:

• The SSRF: only prefill workers running the P2pNcclConnector KV-transfer connector. The advisory says an API caller who can reach such a worker can send out that request’s KV cache, which holds prompt text, and can also block the worker.
• The logprobs crash: an engine with a KV connector, such as in a prefix-caching setup. The advisory names evaluation workloads against vLLM with LMCache as the likeliest real-world case.
• The Rust gRPC trio and the disaggregated endpoint: only if you expose those frontends.
• The multimodal ones: only on multimodal models and endpoints. One advisory notes that vLLM’s API key is optional, so a deployment without an authentication layer in front is reachable without privileges.

A vLLM instance reachable only by your own trusted services is a smaller problem, though not zero.

What can you do besides upgrading?

Upgrade to 0.32.0 or later, then read the release notes before you roll it out. The breaking change to watch is in 0.31.0: per-request mm_processor_kwargs and media_io_kwargs are now rejected unless the server runs with --trust-request-mm-kwargs. Clients that send them will start getting errors.

Until you can upgrade, the advisories offer these workarounds:

• Logprobs crash: drop the KV connector (remove the --kv-transfer-config setting), or strip prompt_logprobs, logprobs and echo from inbound requests at a gateway in front of vLLM.
• Per-request multimodal kwargs: reject non-empty mm_processor_kwargs at the API layer, and leave the override on only for trusted clients.
• SSRF: the advisory’s own fix is to stop user-supplied request IDs reaching the connector. We did not see a configuration workaround in the text we read, so removing that connector from anything reachable by outside callers is the obvious stopgap, which is our reading.

What is still unknown?

• Exploitation. We found no report of any of these being used in the wild, and none of the sources claims it.
• Whether the CVE records will change. GitHub marks the October 25 batch unreviewed, so ratings and affected ranges may be revised, as the Nemotron-VL discrepancy already suggests.
• The two October 20 advisories. No CVE showed up in our search yet.
• Real-world exposure. We have no data on how many deployments run a KV connector or the Rust frontend.

What to keep in mind

These are our observations:

• The CVE numbers arrived after the fixes. The SSRF fix shipped in 0.24.0 on June 29 and its advisory is dated October 9, 102 days later by our count. Teams that track vulnerabilities by CVE could have missed these until the records appeared, so it is worth rerunning scans this week.
• Most of this is availability, in a shared engine. A single malformed request can take out other tenants’ work, which makes request validation and gateway limits in front of vLLM worth more than any single patch.
• Check Pillow separately. vLLM 0.32.0 raised its Pillow floor to 12.3.0, while the Pillow advisory we read (GHSA-5x8w-8jj5-q52h, a FlashPix decoding flaw that needs the optional olefile package) lists 12.3.0 as still affected and 13.0.0 as the fix. We did not check whether your images ship olefile.
• An exposed inference server is a service like any other. Our Railway report and the Brotli write-up show the same pattern of a shared component quietly carrying risk.

Editorial review: October 25, 2026 (AI). Prepared from the vLLM project’s GitHub advisories (the pages for the SSRF, the logprobs crash, the multimodal kwargs and the video frame-count issues read in full; the others’ headers and opening summaries read), GitHub’s advisory records CVE-2026-116172 to CVE-2026-116181 (GitHub API) and the vLLM 0.31.0 and 0.32.0 release notes. We did not run vLLM, reproduce any issue or contact the project. Ratings are those shown in the records and may change. The records and pages may have changed since our reading.