vLLM CVE-2026-73558: A Kernel Overflow That Mixed Users' Outputs

On 8 September 2026, the vLLM project published GHSA-7m6h-x95x-82q5 (CVE-2026-73558): an integer overflow in a CUDA activation kernel could place part or all of one user's inference output into another user's response in the same batch. The reporter reproduced a complete copy, where the last response in a batch became an exact duplicate of the first.

It was one of eight vLLM advisories published between 4 and 17 September. The others cover SSRF and local file read in a model processor, a bypass of the fix for CVE-2025-62164, and several request-driven denial of service bugs. All are fixed in releases from 0.24.0 to 0.28.0.

What's affected

The cross-user leak:

• CVE-2026-73558 (medium, 5.3): the expression blockIdx.x * 2 * d in act_and_mul_kernel overflows. The advisory says that when 2^32 is divisible by d, one request's computation can read another's data. The reporter used meta-llama/Llama-3.2-1B-Instruct, where d is 8192, with a batch of 17 and sequence length 16384. Affects versions before 0.27.0, fixed in 0.27.0 (uploaded 10 August 2026).

The rest of the September batch:

• CVE-2026-73560: the processor for MiMoV2OmniForCausalLM called requests.get on image and audio URLs and opened local paths directly, skipping the MediaConnector checks earlier SSRF advisories added. The advisory notes the OpenAI chat path was protected, but library use through LLM.generate(multi_modal_data=...) and batch jobs were not. Fixed in 0.26.0.
• CVE-2026-73557: the follow-up guard for CVE-2025-62164 used a PyTorch context that toggles process-global state, so two prompt-embedding parts in one request could race and load an invalid sparse tensor. Requires --enable-prompt-embeds, which is off by default. Affects 0.21.0 up to 0.26.0.
• CVE-2026-57173: the audio decode duration guard was wired only into /v1/audio/transcriptions. Audio in /v1/chat/completions had no limit, so a few-KB file could expand to gigabytes and get the worker killed for running out of memory. Fixed in 0.24.0.
• CVE-2026-73556: a regex denial of service in the lm-format-enforcer structured output backend, missed by an earlier fix to the xgrammar and outlines backends. Fixed in 0.26.0.
• CVE-2026-73555: validation errors leaked file paths, the OS username and the Python version to unauthenticated callers. Fixed in 0.26.0.
• CVE-2026-71486: the derender endpoints decoded caller-supplied token ID lists with no size bounds. Fixed in 0.26.0.
• CVE-2026-69147: a request could pick the PyNvVideoCodec GPU decoder at runtime, allocating GPU memory that startup budgeting never reserved. Fixed in 0.28.0.

How to check if you're exposed

Get the version:

python -c "import vllm; print(vllm.__version__)"
curl -s http://localhost:8000/version

Anything below 0.28.0 has at least one of these. For CVE-2026-73558, exposure depends on how you serve:

• Shared serving with batching. If requests from different users or tenants land in the same batch, which is how vLLM normally gets its throughput, the leak is a confidentiality issue between them. The advisory says an attacker can craft requests to be batched with a victim's and receive the victim's output.
• Single-tenant or offline batch jobs. If every request in a batch belongs to the same user or job, the overflow corrupts outputs but doesn't cross a trust boundary.

For CVE-2026-73560, check whether you serve the MiMo V2 Omni architecture and whether any code passes user-supplied strings into multi_modal_data:

grep -rn "multi_modal_data" --include=*.py .

For CVE-2026-57173 and CVE-2026-73555, check whether the server runs without --api-key. Both are reachable unauthenticated in that case.

What to do now

1. Upgrade to vLLM 0.28.0 or later to close the September batch. 0.30.0 also closes the October batch, and 0.31.0 is current.
2. If you serve multiple tenants from one engine and ran a version below 0.27.0, assume some responses could have contained another user's output. Decide with your privacy team whether that needs review or notice.
3. Leave --enable-prompt-embeds off unless you need it. It is the precondition for CVE-2026-73557 and for the original CVE-2025-62164.
4. Never pass raw user URLs or paths into multi_modal_data in offline or batch code. Fetch and validate media yourself, then pass bytes or images.
5. Set --api-key so the unauthenticated bugs in this batch become authenticated ones.
6. Block egress from inference hosts to cloud metadata endpoints. It limits the damage from SSRF bugs like CVE-2026-73560.

Why it matters

Most multi-tenant AI risk discussion focuses on prompts and shared caches. CVE-2026-73558 is a reminder that the compute kernel is also a tenant boundary. When many users share a batch, an integer overflow in index math becomes a data leak, and nothing at the API layer can detect it.

The other theme is incomplete fixes. Three advisories here are siblings or follow-ups of earlier ones: a model processor added after the SSRF hardening, a ReDoS guard applied to two of three backends, and a race in the guard for CVE-2025-62164. When you see a fix for one path, check its siblings in your own code too.

Try it yourself

List every vLLM deployment you run and note two things for each: the version, and whether more than one tenant shares a batch. That second column tells you where CVE-2026-73558 was a data leak rather than a bug. Here's how vulnerability management ties version, exposure and owner together:

Click through it at your own pace, or open it full screen.

Quick check

Sources

• GHSA-7m6h-x95x-82q5: vLLM cross-user data leak (CVE-2026-73558)
• GHSA-4hhp-h66f-j5j7: SSRF and local file read in MiMoV2OmniMultiModalProcessor (CVE-2026-73560)
• GHSA-pr7f-p5mw-fc87: Incomplete CVE-2025-62164 remediation (CVE-2026-73557)
• GHSA-hcwq-8wjf-3gcr: Unauthenticated audio decompression bomb in chat completions (CVE-2026-57173)
• GHSA-48jh-3gj7-fg8v: ReDoS in the lm-format-enforcer backend (CVE-2026-73556)
• GHSA-hwrm-c4cx-rf4j: Path and username disclosure via validation errors (CVE-2026-73555)
• GHSA-8737-qx52-hjff: Unbounded derender endpoints (CVE-2026-71486)
• GHSA-8pw2-6jv3-mj5j: Request-selected PyNvVideoCodec decode bypasses VRAM reservation (CVE-2026-69147)
• vllm on PyPI