CVE-2026-114049

vLLM can apply one client’s token restrictions to another client’s output

vLLM · V1 batched sampling

First documented disclosure · Review checkpoint

Summary

A reused batch slot can impose another client’s vocabulary on an unrestricted generation request.

Severity and exploitation evidence

Medium · 6.3/10 · CVSS 4.0. Severity source.

Exploitation not established: The reporter and maintainers describe a reproducible batch-state flaw. Deliberate attacks on a deployed service are not established.

Exploitation evidence source

Technical severity is not a measure of observed attacks or of risk to your deployment. Attempts, demonstrations, and successful compromise retain the qualifications in the source.

How the weakness works

Batch compaction copies a token mask to its new slot but leaves the old mask populated. An unrestricted request can inherit the vacated slot while token filtering remains active.

Conditions required

Concurrent generation on the same engine, a constrained request remaining active and the right slot-reuse order. The caller needs access to a generate endpoint.

Potential impact

Limited output manipulation through a vocabulary restriction. The reports do not establish arbitrary text substitution or disclosure of other clients’ prompts.

Affected versions and configurations

Versions before 0.31.0 per VulnCheck and vLLM.

Fix and mitigation status

0.31.0 per vLLM.

Practical next steps

Upgrade and test that mixed concurrent requests retain independent token allowlists. Authenticate all reachable inference routes.

Operating lesson

Clear request-specific sampling state whenever a shared batch slot changes owners.

Evidence and limits

The public May 28 bug report predates the October 6 security advisory and October 21 CNA. A different swap_states bug in the same tensor had its own fix.

Sources