CVE-2026-93989: vLLM Privilege Escalation Vulnerability

CVE-2026-93989 Overview

CVE-2026-93989 affects vLLM through version 0.29.0, a high-throughput inference and serving engine for large language models. The vulnerability resides in SamplingParams.update_from_tokenizer(), which fails to validate bad_words token indices against the model's generation output width. An authenticated attacker submitting crafted bad_words values can supply out-of-bounds token indices that corrupt the logits memory of concurrent requests. The result is cross-request data corruption where different in-flight HTTP requests return incorrect tokens. The issue is classified under CWE-129: Improper Validation of Array Index.

Critical Impact
Out-of-bounds token indices in bad_words can corrupt logits memory across concurrent inference requests, causing in-flight requests from other users to return incorrect tokens.

Affected Products

vLLM inference engine versions through 0.29.0
Deployments exposing the vLLM HTTP API with multi-tenant or concurrent request handling
LLM serving platforms embedding vulnerable vLLM builds

Discovery Timeline

2026-09-19 - CVE-2026-93989 published to the National Vulnerability Database
2026-09-22 - Last updated in NVD database

Technical Details for CVE-2026-93989

Vulnerability Analysis

vLLM allows API clients to specify bad_words, a list of token sequences the sampler must suppress during generation. The SamplingParams.update_from_tokenizer() routine converts these words into token identifiers and stores them for use during logits post-processing.

The function does not verify that each resulting token index falls within the model's vocabulary width used for the generation output tensor. When a supplied token identifier exceeds that width, downstream logic writes suppression values outside the intended memory region. Because vLLM batches concurrent requests into shared GPU tensors, that out-of-bounds write lands in logits belonging to other in-flight requests. Affected users receive tokens influenced by another caller's suppression mask rather than their own prompt.

The impact is a confidentiality and integrity issue for concurrent tenants sharing the same vLLM worker, though no direct memory disclosure or code execution has been demonstrated. Review the VulnCheck advisory on vLLM cross-request logits corruption for additional context.

Root Cause

The root cause is missing bounds checking on user-supplied token identifiers before they are used as array indices against the logits tensor. See the vulnerable logic in sampling_params.py lines 694-753 and the sampler helper in bad_words.py. The absence of validation matches CWE-129.

Attack Vector

Exploitation requires network access to the vLLM inference endpoint and low-privilege API credentials sufficient to submit generation requests. The attacker crafts a request containing bad_words entries whose tokenization produces identifiers outside the model's output vocabulary width. Concurrent legitimate requests processed in the same batch then receive corrupted logits and return altered tokens.

// Example exploitation code (sanitized)
No verified proof-of-concept code is publicly available. See the vendor pull request at
https://github.com/vllm-project/vllm/pull/48824 for the corrective implementation.

Detection Methods for CVE-2026-93989

Indicators of Compromise

Generation requests containing bad_words entries that tokenize to identifiers larger than the model vocabulary size.
Unexpected or nonsensical tokens returned to unrelated concurrent API consumers during otherwise valid inference runs.
Application logs showing sampler warnings, tensor index anomalies, or unexpected token-id values emitted from vLLM workers.

Detection Strategies

Instrument the vLLM API gateway to inspect bad_words parameters and flag entries producing token identifiers outside the model's configured vocabulary width.
Compare returned token distributions against baseline outputs for identical prompts to identify cross-request corruption events.
Track vLLM version metadata across serving nodes and alert on any instance running 0.29.0 or earlier.

Monitoring Recommendations

Ingest vLLM application and access logs into a centralized analytics platform with retention sufficient for post-incident review.
Alert on API clients that repeatedly submit oversized or malformed bad_words payloads.
Monitor GPU worker error counters and out-of-range index warnings emitted by the sampler.

How to Mitigate CVE-2026-93989

Immediate Actions Required

Upgrade vLLM to a release that incorporates the fix from Pull Request #48824 once available in a tagged version.
Restrict access to the vLLM HTTP API to authenticated, trusted clients using network controls and API gateway authorization.
Add server-side validation that rejects bad_words entries producing token identifiers outside the model's vocabulary width.

Patch Information

The upstream fix is tracked in vllm-project/vllm Pull Request #48824, which adds bounds checking against the model's generation output width before token identifiers are used to index the logits tensor. Operators should track the vLLM project repository for the release containing the merged patch and update all serving nodes accordingly.

Workarounds

Disable acceptance of the bad_words parameter at the API gateway until vulnerable nodes are patched.
Deploy per-tenant vLLM workers to eliminate cross-request batching between untrusted callers.
Enforce input schema validation that caps bad_words string length and rejects tokens outside the known vocabulary.

bash

# Configuration example
# Example API gateway rule to strip bad_words from inbound vLLM requests
# (adapt to your reverse proxy or WAF configuration language)
request_body_filter {
  json_remove_field: "bad_words"
  applies_to_path: "/v1/completions"
  applies_to_path: "/v1/chat/completions"
}