vLLM: integer overflow in the activation CUDA kernel leaks another batched request's output

CVSS 5.3CVE-2026-73558AI/ML frameworks & servingcurated

Impact

An integer overflow in the blockIdx.x * 2 * d indexing inside act_and_mul_kernel makes the kernel consume a neighbouring request's input from the same batch, so a response can come back carrying part or all of another user's inference result. Continuous batching mixes concurrent requests into one batch by design, so on any endpoint serving more than one tenant this is a direct cross-tenant leak of generated content - no host access, no driver bug, no privilege escalation involved, just a request to the same server. It needs tensor dimensions large enough for the index to overflow, which is why the record rates attack complexity high, and the same condition can surface accidentally rather than by attack. This is the class of flaw that undermines the premise of a shared inference endpoint.

Who can reach it

Any client whose request lands in the same inference batch as the victim's. Unauthenticated on the common deployment where no API key is configured. No access to the node, the GPU or the driver is required.

What to do

Upgrade to vLLM 0.27.0 (fix in commit 451227c) and roll the inference deployment process by process, draining in-flight requests. No node drain, reboot or driver change. There is no configuration mitigation short of not batching different tenants' requests together, which costs the throughput batching exists to provide.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-73558 https://github.com/vllm-project/vllm/security/advisories/GHSA-7m6h-x95x-82q5 https://github.com/vllm-project/vllm/commit/451227cb3ff07989698fed982c2d3e4300257924 https://github.com/vllm-project/vllm/releases/tag/v0.27.0

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.