CVE-2026-93840 in vLLM
Summary
by MITRE • 09/18/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified in vLLM versions prior to 0.29.0 represents a critical logic error within the token sampling mechanism, specifically located in the SamplingParams._validate_allowed_token_ids() method. This function is designed to enforce constraints on which tokens are permitted during text generation by validating user-supplied allowed token IDs against the model's output vocabulary. However, the implementation contains a fundamental flaw where it compares these input identifiers against the length of the tokenizer rather than the actual width of the model's output logits. In large language models deployed via vLLM, the tokenizer vocabulary size and the model's logit dimension are often distinct values due to architectural decisions such as embedding layer resizing or specialized token handling. This discrepancy creates a validation bypass that allows attackers to supply token identifiers that exceed the valid range for the current inference batch but fall within the broader tokenizer vocabulary limits.
When an attacker provides these out-of-bounds token IDs, they successfully pass the flawed validation check and proceed into the LogitBiasState management logic. The core technical consequence of this error is the corruption of the GPU logits state. Because the system assumes the provided tokens are valid indices for the current model output, it attempts to apply biasing operations using these invalid indices. This results in memory access violations or undefined behavior within the CUDA kernels responsible for processing logit biases. Since vLLM handles concurrent requests by batching them together on the GPU, this corruption does not remain isolated to a single request. Instead, the corrupted logits state propagates across the batch, affecting other legitimate users' inference processes.
The operational impact of this vulnerability is severe, as it enables unauthorized token sampling and potential denial of service conditions. Attackers can force the model to sample tokens that are explicitly outside their designated allowlists, effectively bypassing safety filters or content restrictions implemented through allowed_token_ids constraints. Furthermore, because the corruption affects the shared GPU memory state used for concurrent inference, multiple users may experience degraded performance, incorrect outputs, or complete request failures due to the instability introduced by the malformed logit biases. This undermines the reliability and security guarantees of multi-tenant LLM serving environments where strict isolation between user requests is essential.
To mitigate this risk, organizations must upgrade vLLM to version 0.29.0 or later, which corrects the validation logic to properly compare allowed token IDs against the model output logits width rather than the tokenizer length. This ensures that only tokens within the valid inference range are processed by the LogitBiasState machinery. Additionally, defensive coding practices should be adopted where input parameters from untrusted sources are rigorously validated against both static configuration limits and dynamic runtime tensor shapes before being passed to low-level GPU kernels. Monitoring for unusual patterns in token sampling requests can also help detect exploitation attempts of this logic flaw in production environments.
This vulnerability is categorized under CWE-20, which refers to Improper Input Validation, as the system fails to verify that user-supplied data conforms to expected constraints before processing it. From a threat modeling perspective aligned with MITRE ATT&CK techniques, this aligns with T1564.003, Hidden Files and Directories, in the context of hiding malicious intent within valid-looking requests, or more accurately T1059 Command and Scripting Interpreter if viewed as bypassing execution controls, though it is most closely related to privilege escalation via logic flaws that allow unauthorized state manipulation. The failure to validate input against the correct domain boundary allows an attacker to manipulate internal system states in ways not intended by the software architecture.