EUVD-2026-107000
GHSA-qcgg-947w-p2vj
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessReach unauthenticated /invocations endpoint
-
DeliveryFlood concurrent allowed_token_ids-constrained requests
-
ExploitTrigger stale mask in condense()
-
ExecutionVictim request reuses tainted batch slot
-
ImpactVictim output constrained to attacker allowlist
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Expected behavior violation
|
| Exploitation Conditions | Exploitation requires that the vLLM server expose the generation API (notably the unauthenticated /invocations endpoint) and that the attacker use constrained/guided decoding that populates allowed_token_ids, submitted as many concurrent requests to force batch-slot recycling. The defect is in InputBatch.condense() failing to clear stale allowed_token_ids rows. Key limiting factors: it is a race condition (CVSS AC:H plus attack requirement AT:P), so success is timing- and load-dependent and non-deterministic; it only manifests under concurrent multi-tenant traffic; and it is fixed in vLLM 0.31.0, so only deployments running versions before 0.31.0 are affected. Impact is limited to degrading/constraining another client's output (integrity), with no read access to victim data. |
| Impact | This is a genuine but moderate-priority issue, not a critical one. The CVSS 4.0 score of 6.3 (Medium) is driven by a network attack vector (AV:N) and no required privileges (PR:N) - the reachable path is the unauthenticated /invocations endpoint - but it is substantially tempered by high attack complexity (AC:H) and a present attack requirement (AT:P), reflecting that exploitation depends on winning a race to reuse recycled batch slots under concurrent load. Impact is narrow: only integrity is affected and only at Low (VI:L), with confidentiality (VC:N) and availability (VA:N) explicitly unaffected - the flaw lets an attacker constrain/degrade another client's generated output, not read it or crash the service. No EPSS score, KEV listing, or POC was provided in the input, so exploitation likelihood signals are absent rather than low. Note a labeling conflict: the 'Information Disclosure' tag contradicts the CVSS vector (VC:N) and the description, which describe an integrity manipulation (CWE-440, expected-behavior violation), not a data leak - treat the integrity framing as authoritative. Overall: a legitimate multi-tenant correctness/integrity defect worth patching, but the timing dependency and limited impact make it a routine-priority fix rather than an emergency. |
| Exploit ScenarioDerived | An attacker with network access to a vLLM server's unauthenticated /invocations endpoint submits many concurrent generation requests that carry token-allowlist constraints (allowed_token_ids). Because InputBatch.condense() leaves stale allowed_token_ids rows when batch slots are recycled, a victim's unconstrained request that lands on a reused slot silently inherits the attacker's token allowlist, corrupting or constraining the victim's output. No public exploit was identified at time of analysis, and success depends on winning the concurrency race. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 21, 2026
Concurrent constrained-decoding traffic against vLLM servers running versions before 0.31.0 can leave a stale token allowlist in a recycled batch slot, so a victim's unrestricted generation request is silently constrained to the attacker's token set. The flaw is in InputBatch.condense(), which recycles finished request slots without clearing allowed_token_ids; remote unauthenticated attackers who can reach the generation API, including the unauthenticated /invocations endpoint, can trigger it by submitting many concurrent constrained requests while a race with slot reuse is won. Impact is integrity-only - the victim's output is degraded or steered, but no victim data is read - and success is timing- and load-dependent (CVSS AC:H with attack requirement AT:P). No public exploit code or confirmed active exploitation has been identified at time of analysis, and the issue is fixed in vLLM 0.31.0.
RemediationAI
Upgrade to vLLM 0.31.0 or later, which corrects InputBatch.condense() so stale allowed_token_ids rows are cleared before slot reuse; follow the vendor advisory at https://github.com/vllm-project/vllm/security/advisories/GHSA-6cxc-2vcg-w5qc and the VulnCheck advisory for the confirmed fix. If upgrading immediately is not possible, the highest-value compensating control is to stop exposing /invocations and the generation API to untrusted clients by placing an authenticating reverse proxy or API gateway in front of it and allowlisting callers - the trade-off is added latency and an operational dependency, and it does nothing against a malicious authenticated tenant sharing the same process. Second, disable constrained/guided decoding for tenants that do not need it (reject response_format, grammar and JSON-schema constrained requests at the ingress), which removes the attacker's ability to populate allowed_token_ids; the trade-off is loss of structured-output guarantees for legitimate users. Third, shard tenants across separate vLLM processes or instances rather than sharing one batcher, and cap per-client concurrency so slot recycling pressure is reduced; both cost extra GPU memory and capacity, and isolation by process is the only option that fully removes the cross-tenant race for unpatched hosts.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
vLLM serves LLM inference using continuous batching: an InputBatch object holds per-slot state for in-flight sequences, and InputBatch.condense() compacts that structure when requests finish, moving surviving sequences into freed slots. Each slot carries request-scoped fields, including allowed_token_ids, the allowlist used by guided/constrained decoding backends (such as outlines, xgrammar, or lm-format-enforcer) to force structured output. condense() moves or reuses slots but, before 0.31.0, does not reset allowed_token_ids on the rows it recycles, so a later request assigned to that slot inherits the previous client's allowlist even though it never requested constrained decoding. This is classified CWE-440 (Expected Behavior Violation): the per-request state reset that the batching logic implicitly assumes does not happen. Because it is a race between request completion, slot recycling, and new-request admission, it is non-deterministic and only manifests under concurrent multi-tenant load against the generation API. The affected package is cpe:2.3:a:vllm-project:vllm:*:*:*:*:*:*:*:* for all releases before 0.31.0; the leak affects output integrity only, not confidentiality, since the attacker cannot read victim prompts or responses.
Know when Vllm gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
Reachable unauthenticated over the network (AV:N/PR:N) but exploitation is a non-deterministic batch-slot race (AC:H); only victim output integrity is affected at Low (I:L), with no confidentiality or availability impact.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
Lifecycle Timeline
1DescriptionCVE.org
vLLM before 0.31.0 contains a cross-request mask leak in InputBatch.condense() that allows remote attackers to constrain other clients' outputs by leaving stale allowed_token_ids rows. Attackers can submit concurrent constrained generate requests, including via unauthenticated /invocations, so recycled batch slots apply their token allowlist to victims' unrestricted requests.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Related Vulnerabilities in vLLM Cache and Resource Consumption Vulnerabilities
View all 7vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Rated critical severity (CVSS 10.0
vllm-project vllm version v0.6.2 contains a vulnerability in the MessageQueue.dequeue() API function. Rated critical sev
Information exposure in vLLM inference engine versions 0.8.3 to before 0.14.1. Invalid image requests to the multimodal
Timing-based API key recovery in vLLM before 0.11.0rc2 can let remote attackers bypass bearer-token authentication on de
vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Rated high severity (CVSS 7.5), th
vLLM before version 0.14.1 contains a server-side request forgery vulnerability in the MediaConnector class where incons
Out-of-memory worker crashes in vLLM can be induced by a single small compressed audio payload submitted to the /v1/chat
vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Rated medium severity (CVSS 6.5),
GPU memory exhaustion in vLLM versions prior to 0.28.0 lets an attacker with low-privileged API access (PR:L in the CVSS
Multimodal inference requests to vLLM deployments running versions prior to 0.28.0 can trigger a process-level assertion
Uncontrolled resource consumption in vLLM's OpenAI-compatible completions endpoint allows any authenticated API client t
Vllm versions up to 0.12.0 is affected by allocation of resources without limits or throttling (CVSS 6.5).
Exploit-DB