CVE-2026-93592: vLLM: negative token ID crashes embeddings engine

HIGHPoC AVAILABLECISA: TRACK*

Published September 18, 2026

CISO Take

vLLM versions before 0.28.0 do not validate the lower bound of token IDs on the /v1/embeddings and /pooling endpoints, so a single unauthenticated request containing a negative token ID triggers a CUDA device-side assertion that poisons the GPU context. Every later request fails until the process is restarted, so one packet can take an inference node offline. Public PoC code exists and the attack is low complexity over the network with no privileges, but the EPSS score is low (0.00544, around the 56th percentile), it is not in CISA KEV and CISA SSVC rates it TRACK*, so this is not a sign of mass exploitation yet. Exposure matters most: any vLLM embeddings or pooling endpoint reachable from untrusted networks, or without an authenticating gateway, is trivially knocked over. Upgrade to vLLM 0.28.0 or later, and until then block untrusted access to these endpoints or validate token IDs at a gateway.

Sources:NVDEPSSGitHub Advisoryvulncheck.comATLAS

What is the risk?

High severity (CVSS 7.5) with an availability-only impact. Exploitation is trivial: one HTTP request, no authentication, no user interaction. A public PoC exists, but EPSS is low (0.00544, top 56%), there is no KEV listing and no Nuclei template, and SSVC is TRACK*, which suggests opportunistic rather than widespread exploitation. Real-world risk depends on exposure. Internet-facing or multi-tenant vLLM deployments with no authentication layer are at highest risk. Because recovery needs a process restart, the outage persists until someone intervenes, and an attacker can repeat it right after each restart. There is no confidentiality or integrity impact.

How does the attack unfold?

Discovery

Attacker finds an exposed vLLM server with embeddings or pooling endpoints reachable without authentication.

AML.T0049

Exploitation

Attacker sends one request with a negative token ID to /v1/embeddings or /pooling, triggering a CUDA device-side assertion.

AML.T0040

Impact

The GPU context is poisoned and all subsequent requests fail until the vLLM process is restarted.

AML.T0029

Discovery

Attacker finds an exposed vLLM server with embeddings or pooling endpoints reachable without authentication.

AML.T0049

Exploitation

Attacker sends one request with a negative token ID to /v1/embeddings or /pooling, triggering a CUDA device-side assertion.

AML.T0040

Impact

The GPU context is poisoned and all subsequent requests fail until the vLLM process is restarted.

AML.T0029

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
vLLM	pip	—	No patch
96.0K94 dependentsPushed 5d ago27% patched~37d to patchFull package profile →

Do you use vLLM? You're affected.

How severe is it?

CVSS 3.1

7.5 / 10

EPSS

0.5%

chance of exploitation in 30 days

Higher than 46% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Trivial

Exploitation Confidence

medium

○CISA SSVC: Public PoC

○Public PoC indexed (trickest/cve)

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AVNetwork

ACLow

PRNone

UINone

SUnchanged

CNone

INone

AHigh

What should I do?

1 step

1) Upgrade vLLM to 0.28.0 or later, which validates the token ID lower bound. 2) If you cannot patch immediately, do not expose /v1/embeddings and /pooling to untrusted networks. Place them behind an authenticated API gateway or reverse proxy and enable vLLM's API key option. 3) Add a gateway or WAF rule that rejects requests where any token ID in the input array is negative. 4) Configure liveness and readiness probes that exercise a real inference call, with automatic restart (Kubernetes, systemd), so a poisoned CUDA context is detected and recovered. 5) Rate limit and monitor for repeated CUDA device-side assertion errors, sudden 5xx spikes and engine restarts in vLLM logs. 6) Inventory all vLLM instances, including internal and shadow deployments, with pip or container image version checks.

What does CISA's SSVC say?

DecisionTrack*

Exploitationpoc

AutomatableYes

Technical Impactpartial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

DoSInferenceAPIAML.T0029- Denial of AI Service AML.T0040- AI Model Inference API Access AML.T0049- Exploit Public-Facing Application

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15-Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.6-AI system operation and monitoring

NIST AI RMF

MANAGE 2.3-Response to unknown risks and incidents

OWASP LLM Top 10

LLM10-Unbounded Consumption

Frequently Asked Questions

What is CVE-2026-93592?

Is CVE-2026-93592 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-93592, increasing the risk of exploitation.

How to fix CVE-2026-93592?

1) Upgrade vLLM to 0.28.0 or later, which validates the token ID lower bound. 2) If you cannot patch immediately, do not expose /v1/embeddings and /pooling to untrusted networks. Place them behind an authenticated API gateway or reverse proxy and enable vLLM's API key option. 3) Add a gateway or WAF rule that rejects requests where any token ID in the input array is negative. 4) Configure liveness and readiness probes that exercise a real inference call, with automatic restart (Kubernetes, systemd), so a poisoned CUDA context is detected and recovered. 5) Rate limit and monitor for repeated CUDA device-side assertion errors, sudden 5xx spikes and engine restarts in vLLM logs. 6) Inventory all vLLM instances, including internal and shadow deployments, with pip or container image version checks.

What systems are affected by CVE-2026-93592?

This vulnerability affects the following AI/ML architecture patterns: model serving, RAG pipelines, embedding services, LLM inference clusters, multi-tenant GPU inference.

What is the CVSS score for CVE-2026-93592?

CVE-2026-93592 has a CVSS v3.1 base score of 7.5 (HIGH). The EPSS exploitation probability is 0.54%.

What is the AI security impact?

Affected AI Architectures

model servingRAG pipelinesembedding servicesLLM inference clustersmulti-tenant GPU inference

MITRE ATLAS Techniques

AML.T0029Denial of AI Service

AML.T0040AI Model Inference API Access

AML.T0049Exploit Public-Facing Application

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2.6

NIST AI RMF: MANAGE 2.3

OWASP LLM Top 10: LLM10

What are the technical details?

Original Advisory

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.

Exploitation Scenario

An attacker scans for exposed vLLM servers, for example via the /v1/models or /docs endpoints. They send one POST to /v1/embeddings with an input array of token IDs containing a value such as -1. The server passes the value to the GPU embedding lookup, a CUDA device-side assertion fires, and the GPU context becomes unusable. Every subsequent request, including legitimate completions and embeddings, returns errors. The company's RAG assistant and search features go offline. After operations restart the process, the attacker repeats the request on a schedule to keep the service down, or uses it as leverage for extortion or to disrupt a competitor's AI product.

Weaknesses (CWE)

CWE-129Improper Validation of Array IndexPrimary CWE-129Improper Validation of Array Index

CWE-129 — Improper Validation of Array Index: The product uses untrusted input when calculating or using an array index, but the product does not validate or incorrectly validates the index to ensure the index references a valid position within the array.

[Architecture and Design] Use an input validation framework such as Struts or the OWASP ESAPI Validation API. Note that using a framework does not automatically address all input validation problems; be mindful of weaknesses that could arise from misusing the framework itself (CWE-1173).
[Architecture and Design] For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server. Even though client-side checks provide minimal benefits with respect to server-side security, they are still useful. First, they can support intrusion detection. If the server receives input that should have been rejected by the client, then it may be an indication of an attack. Second, client-side error-checking can provide helpful feedback to the user about the expectations for valid input. Third, there may be a reduction in server-side processing time for accidental input errors, although this is typically a small savings.

Source: MITRE CWE corpus.