CVE-2026-93592 Overview
CVE-2026-93592 is a denial-of-service vulnerability in vLLM, an open-source inference and serving engine for large language models. Versions before 0.28.0 fail to validate the lower bound of token IDs in the /v1/embeddings and /pooling endpoints. Unauthenticated attackers can submit a single request containing a negative token ID to crash the inference engine. The malformed input triggers a CUDA device-side assertion that poisons the GPU context. All subsequent requests fail until the process restarts, taking the inference service offline.
Critical Impact
A single unauthenticated HTTP request with a negative token ID renders the vLLM engine unusable until an operator restarts the process.
Affected Products
- vLLM versions prior to 0.28.0
- Deployments exposing the /v1/embeddings endpoint
- Deployments exposing the /pooling endpoint
Discovery Timeline
- 2026-09-18 - CVE-2026-93592 published to NVD
- 2026-09-22 - Last updated in NVD database
Technical Details for CVE-2026-93592
Vulnerability Analysis
The flaw is an improper validation of array index issue [CWE-129]. The /v1/embeddings and /pooling endpoints accept token IDs supplied by the client but do not enforce a lower bound on those values. When a negative integer is passed as a token ID, vLLM forwards it to the underlying CUDA kernel that performs embedding lookups. The kernel triggers a device-side assertion because the index falls outside the embedding table.
Once the assertion fires, the CUDA context becomes invalid. The vLLM worker cannot recover the GPU state within the running process, and every subsequent inference request fails. The service remains degraded until an operator restarts the process, producing a persistent denial-of-service condition from a single malformed request.
Root Cause
Input validation in the embedding and pooling request handlers checks the upper bound of token IDs against the model vocabulary size but does not check that values are non-negative. Because CUDA kernels perform unchecked memory addressing based on the supplied index, an out-of-range negative value corrupts the GPU context rather than producing a recoverable Python exception.
Attack Vector
The attack requires no authentication, no user interaction, and no elevated privileges. An attacker sends an HTTP POST request to /v1/embeddings or /pooling with a JSON payload containing a negative integer in the token IDs field. The engine processes the request, the CUDA assertion fires, and the worker enters an unrecoverable state. Full technical details are available in the GitHub Security Advisory GHSA-25q3-v2hm-8vpf and the VulnCheck Denial of Service Advisory.
Detection Methods for CVE-2026-93592
Indicators of Compromise
- HTTP POST requests to /v1/embeddings or /pooling containing negative integer values in token ID arrays.
- CUDA device-side assertion errors in vLLM worker logs, typically referencing invalid index access in embedding lookup kernels.
- Sudden and sustained HTTP 500 responses from a previously healthy vLLM instance following a specific request.
Detection Strategies
- Parse vLLM stdout and stderr for CUDA error, device-side assert triggered, or embedding index assertion messages.
- Inspect request payloads at an API gateway or reverse proxy for negative integers in token ID fields before they reach the inference engine.
- Correlate an abrupt drop in successful inference response rate with the last request processed to identify the triggering payload.
Monitoring Recommendations
- Track vLLM process uptime and restart frequency as a health signal for exploitation attempts.
- Alert on repeated malformed requests to /v1/embeddings and /pooling from a single source.
- Monitor GPU utilization and CUDA context health metrics to detect poisoned contexts early.
How to Mitigate CVE-2026-93592
Immediate Actions Required
- Upgrade vLLM to version 0.28.0 or later, which validates the lower bound of token IDs.
- Restrict network exposure of the /v1/embeddings and /pooling endpoints to trusted clients only.
- Place vLLM behind an authenticating reverse proxy if it is currently reachable without credentials.
Patch Information
The maintainers addressed the vulnerability in vLLM 0.28.0 by validating that submitted token IDs are non-negative before dispatching them to CUDA kernels. Fix details are documented in the GitHub Security Advisory GHSA-25q3-v2hm-8vpf.
Workarounds
- Deploy an input-validation layer at an API gateway that rejects requests containing negative integers in token ID fields.
- Configure a process supervisor such as systemd or Kubernetes liveness probes to automatically restart vLLM when a CUDA assertion is detected.
- Isolate vLLM inference services on a private network segment and require authentication at the ingress layer.
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
