CVE-2026-93840: vLLM Privilege Escalation Vulnerability

CVE-2026-93840 Overview

CVE-2026-93840 affects vLLM versions before 0.29.0, a high-throughput inference and serving engine for large language models (LLMs). The vulnerability resides in SamplingParams._validate_allowed_token_ids(), which validates allowed_token_ids against the tokenizer length rather than the model output logits width. Attackers can submit token IDs above the output vocabulary that pass validation but corrupt shared GPU logits state through LogitBiasState. The flaw enables concurrent requests to sample tokens outside their intended allowlists, breaking per-request isolation on a shared inference server.

Critical Impact
Remote unauthenticated attackers can corrupt GPU sampling state and influence tokens returned to other users' concurrent inference requests.

Affected Products

vLLM inference server versions prior to 0.29.0
Deployments exposing the vLLM HTTP API to untrusted clients
Multi-tenant LLM serving environments running affected versions

Discovery Timeline

2026-09-18 - CVE-2026-93840 published to NVD
2026-09-22 - Last updated in NVD database

Technical Details for CVE-2026-93840

Vulnerability Analysis

The vulnerability is an improper input validation issue [CWE-129] in vLLM's sampling parameter handling. When a client submits allowed_token_ids in a sampling request, _validate_allowed_token_ids() in vllm/sampling_params.py bounds-checks the values against the tokenizer vocabulary size. The model's output logits tensor can be narrower than the tokenizer vocabulary, so IDs that pass validation may fall outside the valid logits index range.

Downstream, LogitBiasState in vllm/v1/worker/gpu/sample/logit_bias.py applies bias values at those unchecked indices into shared GPU memory used for the batched logits of all in-flight requests. Writes at out-of-range offsets overwrite memory belonging to sibling requests, causing them to sample tokens outside their own allowlists. The result is cross-request state corruption that violates per-tenant output isolation on a shared inference server.

Root Cause

The validator uses the wrong upper bound. _validate_allowed_token_ids() compares submitted IDs to len(tokenizer) instead of the model's output vocabulary width. When the two differ, the check permits token IDs that later index outside the allocated logits tensor.

Attack Vector

Exploitation requires only network access to the vLLM API endpoint and no authentication. An attacker crafts a completion or chat request containing allowed_token_ids values above the model's output logits width. The malformed request is accepted, and the resulting out-of-range writes to LogitBiasState corrupt the batched logits used by concurrent requests from other clients.

python

         self._validate_logprobs(model_config)
         self._validate_logit_bias(model_config)
         self._validate_trace_replay(model_config, speculative_config)
+        self._validate_stop_token_ids(model_config)
         self._validate_logits_processors(model_config)
-        self._validate_allowed_token_ids(tokenizer)
+        self._validate_allowed_token_ids(model_config)
         self._validate_spec_decode(speculative_config)
         self._validate_diffusion(model_config)
         self._validate_structured_outputs(

Source: vLLM commit 5b0e5b6. The patch switches validation to model_config, allowing the bound to reflect the actual output logits width instead of the tokenizer length.

Detection Methods for CVE-2026-93840

Indicators of Compromise

Inference requests containing allowed_token_ids values exceeding the served model's output vocabulary size.
Concurrent users reporting completions containing tokens they did not permit or expect.
Anomalous drift in sampled token distributions during periods of high request concurrency.

Detection Strategies

Inspect API access logs for allowed_token_ids payloads with unusually large integer values relative to the model configuration.
Deploy a proxy or gateway that enforces a hard upper bound on allowed_token_ids before requests reach vLLM.
Correlate output quality regressions with request payload patterns to identify probing behavior.

Monitoring Recommendations

Track the vLLM server version across all deployments and alert on any instance below 0.29.0.
Log rejected sampling parameter validations and monitor for spikes indicating exploitation attempts.
Emit metrics on maximum observed allowed_token_ids per request and alert on outliers.

How to Mitigate CVE-2026-93840

Immediate Actions Required

Upgrade vLLM to version 0.29.0 or later, which contains the fix from pull request #49080.
Restrict network exposure of vLLM endpoints to authenticated internal clients until patching is complete.
Audit multi-tenant deployments for evidence of cross-request output contamination.

Patch Information

The fix is applied in commit 5b0e5b6 and shipped in vLLM 0.29.0. It changes _validate_allowed_token_ids() to validate against model_config so the bound reflects the model's output logits width rather than the tokenizer length. Review the VulnCheck advisory for full technical context.

Workarounds

Place an API gateway in front of vLLM that rejects requests where any allowed_token_ids entry exceeds the model's output vocabulary size.
Disable client-supplied allowed_token_ids on shared multi-tenant endpoints until the upgrade is deployed.
Serve untrusted tenants on isolated vLLM instances so cross-request corruption cannot cross trust boundaries.

bash

# Upgrade vLLM to the patched release
pip install --upgrade "vllm>=0.29.0"

# Verify the installed version
python -c "import vllm; print(vllm.__version__)"