CVE-2026-100654 in vLLM
Summary
by MITRE • 09/26/2026
vLLM before 0.29.0 accepts user-controlled stop_token_ids on the OpenAI-compatible POST /v1/completions and POST /v1/chat/completions endpoints but validates only that the values are integers, not that each token id is within the model vocabulary/logits range. When min_tokens > 0, the stop token ids are used as logits indices to suppress stop tokens, so an out-of-range id reaches a CUDA indexing operation (index_put_) and triggers a device-side assertion. An authenticated API user can send a single malformed completion request that returns 500 Internal Server Error and puts EngineCore into a fatal state, causing subsequent requests to fail until the service is restarted (denial of service).
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/26/2026
The vulnerability resides in vLLM versions prior to 0.29.0 within its OpenAI-compatible API endpoints for completions and chat completions. The system accepts user-supplied stop_token_ids but performs insufficient validation on these inputs. Specifically, the software checks only that the provided values are integers, failing to verify whether each token ID falls within the valid range of the model's vocabulary or logits distribution. This lack of bounds checking creates a critical security gap where malicious actors can exploit the input handling logic to trigger internal system failures.
When the configuration parameter min_tokens is set greater than zero, vLLM utilizes the provided stop_token_ids as indices for suppressing specific tokens during generation. These IDs are directly passed into CUDA operations, specifically index_put_, which expects valid memory offsets within the tensor dimensions defined by the model's vocabulary size. Because the input validation does not enforce upper bounds corresponding to the maximum token ID of the loaded language model, an attacker can supply a stop_token_id that exceeds this limit. This out-of-range value is then used as an array index in GPU kernel execution.
The consequence of providing an invalid index during CUDA indexing operations is immediate and severe. The operation triggers a device-side assertion failure within the NVIDIA CUDA runtime environment. Unlike standard software exceptions that can be caught and handled gracefully, hardware-level assertions on the GPU typically result in the termination of the current processing stream or thread block associated with EngineCore. This leads to an internal server error response being returned to the client, but more critically, it leaves the underlying inference engine core in a fatal, corrupted state.
The operational impact is significant for any service relying on vLLM for high-throughput text generation. Once EngineCore enters this fatal state due to the assertion failure, it becomes unresponsive and unable to process further requests. This effectively results in a denial of service condition where all subsequent API calls fail until the entire vLLM instance or container is restarted by an administrator. Since authentication may be required to access these endpoints, authenticated users with malicious intent can exploit this flaw to disrupt service availability for other legitimate users without needing elevated privileges beyond standard API access.
From a classification perspective, this vulnerability aligns with CWE-125 Out-of-bounds Read and CWE-787 Out-of-bounds Write depending on the specific memory layout accessed by the invalid index, though it primarily manifests as an out-of-bounds write attempt that triggers hardware assertions. In terms of attack vectors, this falls under ATT&CK technique T1499 Endpoint Denial of Service, specifically leveraging resource exhaustion or service disruption through application-level flaws rather than network flooding. The exploitation requires a single malformed request, making it highly efficient for attackers aiming to degrade service reliability.
Mitigation strategies must focus on rigorous input validation at the API layer before any data is passed to the inference engine. Developers should implement strict bounds checking that verifies each stop_token_id against the model's vocabulary size or maximum logits index prior to processing. Additionally, implementing try-catch blocks around CUDA kernel launches can help isolate failures and prevent them from crashing the entire EngineCore instance. Upgrading to vLLM version 0.29.0 or later resolves this issue as it includes proper validation logic for token IDs. Until an upgrade is performed, deploying a reverse proxy with request filtering capabilities that rejects integer values exceeding known model limits can provide temporary protection against exploitation attempts.