CVE-2026-93840: vLLM token ID validation flaw

CISO Take

vLLM before 0.29.0 validates allowed_token_ids against the tokenizer length instead of the model's output logits width. A remote, unauthenticated caller can submit out-of-range token IDs that pass validation, corrupting shared GPU logits state so that concurrent requests may sample tokens outside their allowlists. Severity is medium (CVSS 5.3, integrity-only impact), EPSS sits at 0.00246 (top 85th percentile), there is no known public exploit or Nuclei template, it is not in CISA KEV, and CISA SSVC says TRACK. The practical risk is to multi-tenant deployments that rely on allowed_token_ids to constrain outputs (structured output, classification, or policy enforcement), since the constraint can be silently broken for other users' requests. Upgrade to vLLM 0.29.0 or later, and until then do not expose allowed_token_ids to untrusted clients and validate output downstream.

Sources:NVDEPSSATLASGitHub Advisoryvulncheck.com

What is the risk?

Overall risk is medium and mostly relevant to multi-tenant or shared inference endpoints. Exploitation needs no authentication or interaction and is low complexity, but impact is limited to integrity (CVSS I:L) with no confidentiality or availability effect rated. EPSS is low in absolute terms (0.00246), there is no public exploit or scanner template, and the issue is not in KEV. Risk rises when downstream systems trust allowlist-constrained outputs, for example tool-call selection, enum classifiers, or guardrail-style token restrictions. Note that out-of-range indices in GPU state could also cause unstable behavior, although the advisory only describes integrity corruption.

How does the attack unfold?

Initial Access

Attacker sends requests to an exposed vLLM inference API with no authentication needed.

AML.T0040

Exploitation

Crafted allowed_token_ids above the logits width pass validation against tokenizer length.

AML.T0049

State Corruption

LogitBiasState corrupts shared GPU logits state across the batch.

AML.T0031

Impact

Concurrent requests sample tokens outside their allowlists, breaking output constraints for other users.

AML.T0031

Initial Access

Attacker sends requests to an exposed vLLM inference API with no authentication needed.

AML.T0040

Exploitation

Crafted allowed_token_ids above the logits width pass validation against tokenizer length.

AML.T0049

State Corruption

LogitBiasState corrupts shared GPU logits state across the batch.

AML.T0031

Impact

Concurrent requests sample tokens outside their allowlists, breaking output constraints for other users.

AML.T0031

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

5.3 / 10

EPSS

0.2%

chance of exploitation in 30 days

Higher than 16% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AVNetwork

ACLow

PRNone

UINone

SUnchanged

CNone

ILow

ANone

What should I do?

1 step

1) Upgrade vLLM to 0.29.0 or later (fix in commit 5b0e5b69 / PR 49080). 2) As a workaround, block or strip allowed_token_ids (and logit_bias-style parameters) from untrusted client requests at the API gateway, or enforce that token IDs are below the model's output vocabulary size. 3) Add server-side output validation for any workflow relying on allowlisted tokens rather than trusting decoding constraints alone. 4) Detect by logging requests with unusually large token IDs in allowed_token_ids and alerting on outputs that violate expected allowlists. 5) Isolate tenants onto separate vLLM instances where strong output guarantees are required.

What does CISA's SSVC say?

DecisionTrack

Exploitationnone

AutomatableNo

Technical Impactpartial

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

How is it classified?

DoSData LeakageInferenceAPIAML.T0031- Erode AI Model Integrity 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

Art. 15-Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.6-AI system operation and monitoring

NIST AI RMF

MANAGE 2.3-Responding to unknown risks and system failures

OWASP LLM Top 10

LLM05-Improper Output Handling

Frequently Asked Questions

What is CVE-2026-93840?

vLLM before 0.29.0 validates allowed_token_ids against the tokenizer length instead of the model's output logits width. A remote, unauthenticated caller can submit out-of-range token IDs that pass validation, corrupting shared GPU logits state so that concurrent requests may sample tokens outside their allowlists. Severity is medium (CVSS 5.3, integrity-only impact), EPSS sits at 0.00246 (top 85th percentile), there is no known public exploit or Nuclei template, it is not in CISA KEV, and CISA SSVC says TRACK. The practical risk is to multi-tenant deployments that rely on allowed_token_ids to constrain outputs (structured output, classification, or policy enforcement), since the constraint can be silently broken for other users' requests. Upgrade to vLLM 0.29.0 or later, and until then do not expose allowed_token_ids to untrusted clients and validate output downstream.

Is CVE-2026-93840 actively exploited?

No confirmed active exploitation of CVE-2026-93840 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-93840?

1) Upgrade vLLM to 0.29.0 or later (fix in commit 5b0e5b69 / PR 49080). 2) As a workaround, block or strip allowed_token_ids (and logit_bias-style parameters) from untrusted client requests at the API gateway, or enforce that token IDs are below the model's output vocabulary size. 3) Add server-side output validation for any workflow relying on allowlisted tokens rather than trusting decoding constraints alone. 4) Detect by logging requests with unusually large token IDs in allowed_token_ids and alerting on outputs that violate expected allowlists. 5) Isolate tenants onto separate vLLM instances where strong output guarantees are required.

What systems are affected by CVE-2026-93840?

This vulnerability affects the following AI/ML architecture patterns: model serving, LLM inference servers, multi-tenant inference platforms, constrained decoding pipelines.

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

CVE-2026-93840 has a CVSS v3.1 base score of 5.3 (MEDIUM). The EPSS exploitation probability is 0.25%.

What is the AI security impact?

Affected AI Architectures

model servingLLM inference serversmulti-tenant inference platformsconstrained decoding pipelines

MITRE ATLAS Techniques

AML.T0031Erode AI Model Integrity

AML.T0040AI Model Inference API Access

AML.T0049Exploit Public-Facing Application

Compliance Controls Affected

EU AI Act: Art. 15

ISO 42001: A.6.2.6

NIST AI RMF: MANAGE 2.3

OWASP LLM Top 10: LLM05

What are the technical details?

Original Advisory

vLLM before 0.29.0 validates allowed_token_ids against tokenizer length instead of model output logits width in SamplingParams._validate_allowed_token_ids(). Attackers can supply token IDs above the output vocabulary that pass validation, causing LogitBiasState to corrupt GPU logits state and allow concurrent requests to sample tokens outside their allowlists.

Exploitation Scenario

An attacker with network access to a shared vLLM OpenAI-compatible endpoint sends requests with allowed_token_ids containing values above the model's logits width but below the tokenizer length. Validation passes and LogitBiasState writes corrupt the shared GPU logits state. While the corruption persists, other tenants' concurrent requests that use allowlists (for example a classifier restricted to 'approve'/'deny' tokens) sample tokens outside their allowlist, producing malformed or unintended outputs that downstream automation may act on.

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.