CVE-2026-93592 in vLLM
Summary
by MITRE • 09/18/2026
vLLM versions before 0.28.0 fail to validate the lower bound of token IDs in the /v1/embeddings and /pooling endpoints, allowing unauthenticated attackers to crash the engine by submitting negative token IDs. A single request with a negative token ID triggers a CUDA device-side assertion that poisons the GPU context, causing all subsequent requests to fail until the process restarts.
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 in vLLM versions prior to 0.28.0 represents a critical input validation failure within the model serving engine's embedding and pooling endpoints. Specifically, the system fails to enforce lower bound constraints on token identifiers submitted by clients during inference requests. In large language model architectures, token IDs are integer indices that map to entries in a static vocabulary table. These indices must be non-negative integers falling within the range of zero to the maximum size of the embedding matrix minus one. By omitting checks for negative values, vLLM allows unauthenticated attackers to inject invalid data directly into the computational graph execution pipeline. This lack of sanitization at the API layer bypasses initial preprocessing steps that would normally reject malformed inputs before they reach the core inference logic.
The technical mechanism of exploitation relies on how modern GPU accelerators handle memory access violations and assertion failures. When a request containing a negative token ID is processed, the underlying CUDA kernel attempts to use this invalid index to look up embeddings in the model's weight tensors. Since array indices cannot be negative, this operation triggers an out-of-bounds read or write attempt depending on internal implementation details. In NVIDIA GPU architectures using CUDA, such illegal memory access often results in a device-side assertion failure rather than a silent data corruption. This assertion is designed to halt execution immediately to prevent further undefined behavior, but it has severe side effects for the serving engine. The failure poisons the entire GPU context associated with that process instance.
The operational impact of this vulnerability is significant due to its availability implications and lack of authentication requirements. A single malicious request from an unauthenticated source can cause a CUDA device-side assertion error that renders the GPU context unusable. This does not merely crash the specific thread handling the bad request; it corrupts the state of the entire GPU process running vLLM. Consequently, all subsequent inference requests submitted to this instance will fail with connection errors or timeout exceptions until the service is manually restarted and the GPU context is reinitialized. For production environments relying on high availability for real-time AI applications, this constitutes a severe denial-of-service condition that can disrupt services without requiring any credentials or prior interaction from the attacker.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation as it involves failing to verify that user-supplied input meets expected criteria before processing. Additionally, because it allows an unauthenticated actor to cause service disruption through resource exhaustion via context poisoning, it maps to MITRE ATT&CK technique T1499 Endpoint Denial of Service under the Impact tactic. The attack vector is network-based and remote, making it particularly dangerous in publicly exposed API endpoints where input validation controls are often insufficiently rigorous for edge cases like negative integers.
Mitigation strategies must focus on immediate patching and defensive coding practices. Organizations running vLLM should upgrade to version 0.28.0 or later immediately, as this release includes the necessary bounds checking logic to reject negative token IDs before they reach the CUDA kernels. For environments where upgrading is not immediately feasible, implementing a reverse proxy with strict input validation rules can serve as an interim control layer. This middleware should inspect incoming JSON payloads for embedding requests and explicitly block any request containing negative integer values in the tokens array. Furthermore, deploying monitoring solutions that detect sudden spikes in GPU error logs or context resets can help identify ongoing exploitation attempts of this vulnerability before total service outage occurs.