CVE-2026-115916 in vLLM
Summary
by MITRE • 10/26/2026
vLLM is an inference and serving engine for large language models. Prior to 0.32.0, vllm/tokenizers/hf.py computes max_token_id with an off-by-one upper bound, allowing a pre-tokenized prompt ID equal to the vocabulary size to pass validation. For a tensor-parallel size of one and an exact multiple-of-64 vocabulary, VocabParallelEmbedding.forward does not mask that value before F.embedding uses it, causing a CUDA device-side assertion and terminating the engine. This issue is fixed in version 0.32.0.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/26/2026
The vulnerability resides within vLLM, an open-source inference and serving engine designed for large language models, specifically affecting versions prior to 0.32.0. The core technical flaw stems from a logic error in the tokenization module located at vllm/tokenizers/hf.py. During the validation phase of input prompts, the system calculates the maximum allowed token identifier using an off-by-one upper bound calculation. This mathematical oversight results in the acceptance of pre-tokenized prompt identifiers that are exactly equal to the model's vocabulary size. In a correctly implemented security check, any identifier greater than or equal to the vocabulary size should be rejected as invalid, but this boundary condition allows such out-of-bounds values to pass initial validation checks and proceed deeper into the inference pipeline.
The operational impact of this flaw is most severe under specific hardware and configuration conditions, namely when tensor parallelism is set to one and the model's vocabulary size is an exact multiple of sixty-four. Under these circumstances, the VocabParallelEmbedding forward method fails to apply necessary masking operations before passing the token identifier to PyTorch’s F.embedding function. Because the embedding layer expects indices strictly within the range of zero to vocabulary size minus one, receiving a value equal to the vocabulary size triggers an illegal memory access on the GPU. This results in a CUDA device-side assertion failure, which causes immediate and abrupt termination of the vLLM engine process. While this does not typically allow for arbitrary code execution or remote command injection due to the nature of the crash, it represents a significant denial-of-service vector that can disrupt inference services if an attacker can supply crafted inputs meeting these specific criteria.
From a classification perspective, this vulnerability aligns with CWE-193 Off-by-One Error and CWE-20 Improper Input Validation. The failure to correctly validate input boundaries allows invalid data to propagate through the system until it causes a runtime crash. In terms of attack vectors, this relates to ATT&CK technique T1498 Network Denial of Service, as the exploitation leads directly to service unavailability by crashing the inference engine. Although the vulnerability requires specific configuration constraints such as tensor-parallel size one and vocabulary alignment with sixty-four multiples, it highlights a critical gap in input sanitization within high-performance machine learning serving infrastructure.
To mitigate this risk, organizations running vLLM must upgrade immediately to version 0.32.0 or later where the off-by-one error has been corrected. For environments that cannot update instantly due to dependency constraints, implementing strict pre-processing filters on incoming prompts can serve as a temporary workaround. These filters should explicitly reject any token identifiers greater than or equal to the known vocabulary size of the deployed model before they are passed to the vLLM engine. Additionally, monitoring system logs for CUDA assertion errors and setting up automated restarts with health checks can help maintain service availability during periods when patching is delayed. Regular auditing of input validation logic in custom integrations with large language models is also recommended to prevent similar boundary condition vulnerabilities from being introduced in future deployments.