CVE-2026-93989: vLLM bad_words OOB index corrupts

CISO Take

vLLM through 0.29.0 fails to validate user-supplied bad_words token indices against the model's output width, so an authenticated low-privilege caller can write out-of-bounds into logits memory shared with other in-flight requests, causing different users' requests to receive wrong tokens. The CVSS 4.3 score is modest and no confidentiality impact is rated, but the integrity effect matters in multi-tenant inference: one tenant can silently alter another tenant's model outputs, which is hard to detect and can undermine downstream decisions or guardrail checks. Exploitation likelihood is low-to-moderate (EPSS 0.2%, top 91st percentile), the CVE is not in CISA KEV, no public exploit or Nuclei template exists, and CISA SSVC says TRACK. Upgrade to a vLLM release containing the fix from PR #48824 (later than 0.29.0), and until then reject or sanitize the bad_words parameter at your API gateway for shared or multi-tenant deployments.

Sources:NVDEPSSGitHub AdvisoryATLASvulncheck.com

What is the risk?

Medium overall. The attack is network-reachable, low complexity, needs only low privileges (any valid API caller who can set sampling parameters) and no user interaction. Impact is limited to integrity (I:L); no confidentiality or availability impact is rated, though memory corruption could plausibly cause instability in some configurations. Risk is highest for shared, multi-tenant or public-facing vLLM endpoints and lowest for single-tenant internal deployments where all callers are trusted. There is no known in-the-wild exploitation, no public PoC, and no KEV listing, so urgency is routine-to-elevated rather than emergency.

How does the attack unfold?

Initial Access

Attacker authenticates to a shared vLLM inference endpoint with a low-privilege API key.

AML.T0040

Exploitation

Attacker submits requests with out-of-bounds bad_words token indices that are not validated against the output width.

AML.T0049

Memory Corruption

The sampler writes out of bounds into logits memory used by concurrent batched requests.

Impact

Other tenants' in-flight requests return incorrect tokens, silently compromising output integrity.

AML.T0031

Initial Access

Attacker authenticates to a shared vLLM inference endpoint with a low-privilege API key.

AML.T0040

Exploitation

Attacker submits requests with out-of-bounds bad_words token indices that are not validated against the output width.

AML.T0049

Memory Corruption

The sampler writes out of bounds into logits memory used by concurrent batched requests.

Impact

Other tenants' in-flight requests return incorrect tokens, silently compromising output integrity.

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

4.3 / 10

EPSS

0.2%

chance of exploitation in 30 days

Higher than 10% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AVNetwork

ACLow

PRLow

UINone

SUnchanged

CNone

ILow

ANone

What should I do?

5 steps

Upgrade vLLM to a release that includes the fix from vllm-project/vllm PR #48824 (any version after 0.29.0 that contains it).
As a workaround, block or strip the bad_words field (and any equivalent sampling parameters) from untrusted client requests at a gateway or reverse proxy, or enforce that token indices fall within the model's vocabulary and output width.
Isolate tenants onto separate vLLM instances where cross-tenant integrity is critical.
Detection: log and alert on requests carrying bad_words with unusually large or negative values, and on spikes in output-quality anomalies or sampling errors in shared deployments.
Restrict API access with authentication, per-tenant rate limits and least-privilege API keys.

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?

Data 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

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 previously unknown risks and treatment of identified risks

OWASP LLM Top 10

LLM03-Supply Chain

Frequently Asked Questions

What is CVE-2026-93989?

vLLM through 0.29.0 fails to validate user-supplied bad_words token indices against the model's output width, so an authenticated low-privilege caller can write out-of-bounds into logits memory shared with other in-flight requests, causing different users' requests to receive wrong tokens. The CVSS 4.3 score is modest and no confidentiality impact is rated, but the integrity effect matters in multi-tenant inference: one tenant can silently alter another tenant's model outputs, which is hard to detect and can undermine downstream decisions or guardrail checks. Exploitation likelihood is low-to-moderate (EPSS 0.2%, top 91st percentile), the CVE is not in CISA KEV, no public exploit or Nuclei template exists, and CISA SSVC says TRACK. Upgrade to a vLLM release containing the fix from PR #48824 (later than 0.29.0), and until then reject or sanitize the bad_words parameter at your API gateway for shared or multi-tenant deployments.

Is CVE-2026-93989 actively exploited?

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

How to fix CVE-2026-93989?

1. Upgrade vLLM to a release that includes the fix from vllm-project/vllm PR #48824 (any version after 0.29.0 that contains it). 2. As a workaround, block or strip the bad_words field (and any equivalent sampling parameters) from untrusted client requests at a gateway or reverse proxy, or enforce that token indices fall within the model's vocabulary and output width. 3. Isolate tenants onto separate vLLM instances where cross-tenant integrity is critical. 4. Detection: log and alert on requests carrying bad_words with unusually large or negative values, and on spikes in output-quality anomalies or sampling errors in shared deployments. 5. Restrict API access with authentication, per-tenant rate limits and least-privilege API keys.

What systems are affected by CVE-2026-93989?

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

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

CVE-2026-93989 has a CVSS v3.1 base score of 4.3 (MEDIUM). The EPSS exploitation probability is 0.20%.

What is the AI security impact?

Affected AI Architectures

model servingLLM inference serversmulti-tenant inference platformsagent frameworksRAG 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: Article 15

ISO 42001: A.6.2.6

NIST AI RMF: MANAGE 2.3

OWASP LLM Top 10: LLM03

What are the technical details?

Original Advisory

vLLM through 0.29.0 fails to properly validate bad_words token indices against the model's generation output width in SamplingParams.update_from_tokenizer(). Attackers can supply out-of-bounds token indices that corrupt logits memory of concurrent requests, causing different in-flight HTTP requests to return incorrect tokens.

Exploitation Scenario

An attacker with a low-privilege API key on a shared vLLM endpoint sends repeated completion requests whose bad_words list contains token indices far beyond the model's output width. When the sampler processes the batch, these indices write into logits memory that belongs to other concurrent requests. Other customers' in-flight requests then return incorrect or manipulated tokens, for example corrupting a victim's agent tool-call output, summary or content-moderation verdict. The attacker can time requests to coincide with a target's traffic, but cannot directly read data or control the exact content returned.

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.