EUVD-2026-83284
GHSA-97fp-7cr2-23qc
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessReach multi-tenant vLLM API
-
DeliverySubmit request with out-of-vocab allowed_token_ids
-
ExploitPass tokenizer-length validation
-
ExecutionCorrupt shared GPU LogitBiasState
-
ImpactConcurrent requests sample tokens outside allowlists
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V2 - Validation and Business Logic Array index validation
|
| Exploitation Conditions | Exploitation requires a running vLLM instance (before 0.29.0) serving a model where the tokenizer vocabulary is larger than the model's output logits width - the diff explicitly cites the multimodal case of tokenizer length 128257 vs model output vocab 128256, so the flaw is inert on models where the two sizes are equal. The attacker must submit a request with SamplingParams.allowed_token_ids containing an ID in that gap (>= model_vocab_size) via the inference API. Realized cross-request impact further requires concurrent victim requests executing in the same GPU sampling batch (reflected as AT:P). Limiting factors: the corruption only affects token-sampling constraints (integrity, VI:L; no data theft or crash), the bug is most impactful in shared/multi-tenant deployments, and it does not apply to single-tenant setups or models without a tokenizer/output-vocab mismatch. Authentication requirements are not enforced by the CVSS vector (PR:N), consistent with vLLM's default OpenAI-compatible server exposing endpoints without auth. |
| Impact | This is a moderate-severity integrity issue, not a top priority. The vendor CVSS 4.0 vector (6.3, AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N) correctly frames it as a network-reachable, unauthenticated flaw whose ONLY impact is low integrity (VI:L) - no confidentiality (VC:N) and no availability (VA:N) loss. The AT:P (attack requirement 'present') flag is the key signal: successful exploitation depends on a race condition against concurrent victim requests sharing the same GPU batch, which meaningfully limits reliability. No EPSS score, no CISA KEV listing, and no public POC were provided, so there is no public exploit identified at time of analysis. CONFLICT/NOTE: the input Tags label this 'Information Disclosure,' but the description and CWE-129 (improper validation of array index) describe cross-request LOGITS CORRUPTION causing tokens to be sampled outside their allowlists - that is an integrity/output-manipulation problem, not disclosure; the vendor's own VC:N (no confidentiality impact) confirms the tag is misleading. A secondary data note: the referenced patch diff is Rust code (rust/src/text/lower/token_ids.rs) while the description cites the Python SamplingParams._validate_allowed_token_ids() path - both reflect the same fix (validating against model_vocab_size rather than tokenizer_vocab_size). Overall a real but bounded defect affecting multi-tenant vLLM deployments; patch to 0.29.0 as routine hardening rather than emergency. |
| Exploit ScenarioDerived | An attacker with access to a shared/multi-tenant vLLM inference endpoint submits a completion request whose SamplingParams.allowed_token_ids includes a token ID that is valid in the tokenizer but beyond the model's output logits width (e.g., ID 128256 on a model whose output vocab is 128256 but tokenizer is 128257). The out-of-range index passes validation and corrupts the shared LogitBiasState on the GPU, causing other users' concurrent requests to sample tokens outside their own allowlists. No public POC is provided, and success depends on timing against concurrent requests (AT:P). |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 18, 2026
Sampling-parameter validation in vLLM before 0.29.0 checks the allowed_token_ids allowlist against the tokenizer vocabulary size instead of the model's output logits width, so a remote client calling the OpenAI-compatible inference API can supply token IDs that are valid for the tokenizer but out of range for the model output (the advisory's cited case is a multimodal model with 128257 tokenizer tokens versus 128256 output logits). Those out-of-range IDs pass validation and reach the GPU sampling path, where LogitBiasState's Triton logit-bias kernel indexes past the valid logits row and corrupts shared GPU logits state, causing concurrent victim requests in the same batch to sample tokens outside their own allowlists. The impact is limited to sampling-constraint integrity (no data disclosure, crash, or code execution) in shared or multi-tenant deployments, and it is inert on models whose tokenizer and output vocabularies are the same size; there is no public exploit identified at time of analysis and no confirmed active exploitation (not listed in CISA KEV).
RemediationAI
Upgrade to vLLM 0.29.0 or later, which is the vendor-released fixed version per the advisory; the code change is carried by pull request https://github.com/vllm-project/vllm/pull/49080 and commit https://github.com/vllm-project/vllm/commit/5b0e5b69ac1a3884a6479c9537789c95263cc804, and the vulnerability is tracked as GHSA-wr27-mx79-rg6c with additional detail in the VulnCheck advisory at https://www.vulncheck.com/advisories/vllm-before-0.29.0-cross-request-logits-corruption-via-allowed-token-ids. Until the upgrade can be scheduled, the most effective compensating control is to keep vLLM instances in trusted single-tenant deployments or to run separate GPU processes per tenant so that concurrent requests never share a sampling batch, which removes the cross-request consequence at the cost of higher GPU memory and lower batch efficiency. Because the exposed endpoint is the inference API itself, front it with an authenticating reverse proxy and restrict it to trusted networks rather than relying on vLLM's default unauthenticated OpenAI-compatible server; this does not fix the bug but raises the bar for reaching it. If the application does not need per-request token allowlisting, reject or strip requests that include allowed_token_ids at the gateway, accepting the loss of that constraint feature for legitimate callers; alternatively, validate allowed_token_ids at the gateway against the deployed model's output vocabulary (not its tokenizer vocabulary), which requires maintaining a per-model vocabulary map and rejecting IDs greater than or equal to model output vocab size. Deployments serving models whose tokenizer and output vocabularies are identical are not exposed and can be deprioritized. Patch status per vendor data: Vendor-released patch, vLLM 0.29.0.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in pypi
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The flaw is an instance of CWE-129 (Improper Validation of Array Index) inside vLLM's request-validation layer. SamplingParams._validate_allowed_token_ids() in v0.28.0 compared user-supplied token IDs to the tokenizer length, but the sampler operates on the model's output logits tensor, whose width can be smaller than the tokenizer vocabulary - a common configuration for multimodal and vision-language models, where the tokenizer carries extra special/placeholder tokens that the language-model head never emits. When an ID falls in that gap (>= model output vocab size), the bounds check passes, the ID propagates to LogitBiasState and the Triton _bias_kernel in vllm/v1/worker/gpu/sample/logit_bias.py, and the kernel's mask computation no longer guarantees that loads/stores stay inside the row. Because vLLM batches many concurrent requests into a single GPU sampling step, an out-of-range store writes across row boundaries and alters the logits of neighbouring requests, which then sample tokens that their own allowlists exclude. The upstream fix (PR #49080, commit 5b0e5b69ac1a3884a6479c9537789c95263cc804) changes the Rust validator in rust/src/text/src/lower/token_ids.rs from limits.tokenizer_vocab_size to limits.model_vocab_size, so allowed_token_ids is validated against the model output vocabulary, and it adds regression tests that reject IDs equal to or greater than the model vocab size, negative IDs, mixed valid/invalid lists, and empty lists, plus a GPU test asserting that an out-of-range ID cannot corrupt an adjacent row through the Triton bias kernel (GHSA-wr27-mx79-rg6c).
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:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
Network-reachable, unauthenticated API (AV:N/PR:N), but reliant on a race with concurrent requests and a specific vocab-mismatch model (AC:H); impact is bounded output-sampling corruption (I:L only).
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
DescriptionCVE.org
vLLM before 0.29.0 validates allowed_token_ids against tokenizer length instead of model output logits width in SamplingParams._validate_allowed_token_ids(). Attackers can supply token IDs above the output vocabulary that pass validation, causing LogitBiasState to corrupt GPU logits state and allow concurrent requests to sample tokens outside their allowlists.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
VulDB
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
vLLM 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
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).
Race condition in vLLM's prompt embedding loader allows concurrent API requests to bypass the sparse tensor invariant gu
Exploit-DB