CVE-2026-93989 in vLLM
Summary
by MITRE • 09/20/2026
vLLM through 0.29.0 fails to properly validate bad_words token indices against the model's generation output width in SamplingParams.update_from_tokenizer(). Attackers can supply out-of-bounds token indices that corrupt logits memory of concurrent requests, causing different in-flight HTTP requests to return incorrect tokens.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/20/2026
The vulnerability identified in vLLM versions through 0.29.0 represents a critical input validation failure within the SamplingParams.update_from_tokenizer method. This function is responsible for processing configuration parameters that influence how large language models generate text, specifically handling constraints such as forbidden words or bad_words lists. The core technical flaw lies in the absence of rigorous bounds checking when validating token indices provided by users against the model's vocabulary size and generation output width. In a typical transformer-based architecture like those used by vLLM, the logits tensor represents the raw prediction scores for every possible next token in the vocabulary. When an attacker supplies out-of-bounds token indices, the system fails to reject these invalid inputs before they are processed into memory operations that manipulate the logit array.
This lack of validation allows malicious actors to inject arbitrary integer values that exceed the valid range of token identifiers defined by the model's tokenizer. Instead of triggering a standard error or ignoring the invalid entry, the flawed logic proceeds to use these out-of-bounds indices as pointers or offsets within the logits memory structure. Because vLLM is designed for high-throughput serving and often handles multiple concurrent HTTP requests in parallel using shared GPU resources, this memory corruption does not remain isolated to the offending request. The incorrect manipulation of logit values affects the probability distribution used by subsequent decoding steps, leading to a state where the model's output becomes unpredictable and corrupted.
The operational impact of this vulnerability is severe due to its potential for cross-request interference. Since in-flight HTTP requests share underlying computational resources and memory spaces during generation, corrupting the logits can cause different concurrent users to receive incorrect tokens or garbled text responses. This breaks the isolation guarantees expected in multi-tenant inference environments. Beyond mere data corruption, this behavior could potentially be leveraged for more sophisticated attacks if combined with other vulnerabilities, such as information leakage about internal model states or memory layouts, although the primary immediate risk is service integrity and reliability degradation.
From a classification perspective, this issue aligns closely with CWE-125 Out-of-bounds Read and CWE-787 Out-of-bounds Write, depending on whether the out-of-bounds access results in reading sensitive data or overwriting memory that affects other processes. In terms of attack vectors, it falls under ATT&CK technique T1059 Command and Scripting Interpreter if viewed through the lens of abusing API parameters to execute unintended logic, but more accurately reflects input validation failures common in web services handling complex binary structures. The vulnerability highlights a critical gap in defensive programming practices where assumptions about user-supplied data ranges are not strictly enforced before memory operations occur.
Mitigation strategies must focus on immediate patching and robust input sanitization. Users running vLLM versions up to 0.29.0 should upgrade to the latest stable release as soon as possible, assuming the vulnerability has been addressed in subsequent commits by the development team. For environments where upgrading is not immediately feasible, implementing a reverse proxy or API gateway layer that validates SamplingParams inputs before they reach the vLLM instance can provide a temporary buffer. This external validation should strictly enforce that all token indices fall within the known vocabulary size of the deployed model and adhere to expected data types. Additionally, enabling strict logging for parameter anomalies may help in detecting attempted exploitation attempts during runtime monitoring phases.