CVE-2026-100654: vLLM OpenAI API DOS Vulnerability

CVE-2026-100654 Overview

CVE-2026-100654 is a denial-of-service vulnerability in vLLM, an open-source inference and serving engine for large language models. Versions prior to 0.29.0 accept user-controlled stop_token_ids on the OpenAI-compatible POST /v1/completions and POST /v1/chat/completions endpoints. The server validates only that the values are integers, not that each token ID falls within the model vocabulary range. An authenticated API user can send a single malformed completion request that crashes the inference engine. The failure persists until the service is restarted, denying service to all tenants sharing the deployment.

Critical Impact
A single authenticated request can place the vLLM EngineCore into a fatal state, causing all subsequent inference requests to fail until the service is manually restarted.

Affected Products

vLLM versions prior to 0.29.0
OpenAI-compatible POST /v1/completions endpoint
OpenAI-compatible POST /v1/chat/completions endpoint

Discovery Timeline

2026-09-26 - CVE-2026-100654 published to NVD
2026-09-30 - Last updated in NVD database

Technical Details for CVE-2026-100654

Vulnerability Analysis

The flaw is an improper validation of array index issue [CWE-129] in the request-handling path of vLLM's OpenAI-compatible API. When clients submit a completion request, they may supply stop_token_ids to designate token IDs that terminate generation. vLLM confirms that each value deserializes to an integer but does not verify that the ID is within the model's vocabulary or logits tensor range.

When the request also sets min_tokens > 0, vLLM uses the supplied stop token IDs as indices into the logits tensor to suppress those tokens during the minimum-length window. An out-of-range ID is forwarded to a CUDA index_put_ operation on the GPU. The write triggers a device-side assertion inside the CUDA kernel, raising an exception that propagates up through the EngineCore scheduler.

Because the engine state becomes corrupted after the GPU assertion, the process cannot recover gracefully. The initial request returns 500 Internal Server Error, and every subsequent request fails until an operator restarts the vLLM service.

Root Cause

The root cause is missing bounds checking on stop_token_ids before they are used as tensor indices. The input-validation layer treats the field as a list of integers without comparing each value against the model's vocabulary size. Once the invalid index reaches the CUDA runtime, the device-side assertion poisons the engine context.

Attack Vector

Exploitation requires network access to the vLLM API and valid credentials for the deployment. The attacker sends a crafted POST request with a stop_token_ids value larger than the model vocabulary and min_tokens greater than zero. No elevated privileges, user interaction, or multiple requests are required to achieve the denial of service.

Refer to the GitHub Security Advisory GHSA-v5gm-qgmv-gc6c and the VulnCheck Denial of Service Advisory for additional technical context.

Detection Methods for CVE-2026-100654

Indicators of Compromise

HTTP 500 Internal Server Error responses from /v1/completions or /v1/chat/completions immediately followed by a sustained error pattern for all subsequent requests.
vLLM server logs containing CUDA device-side assertion messages referencing index_put_ or indexSelectLargeIndex.
EngineCore fatal-state log entries and abrupt termination of request scheduling.
Request bodies containing stop_token_ids values that exceed the configured model vocabulary size.

Detection Strategies

Inspect API gateway logs for completion requests carrying unusually large integer values in the stop_token_ids array.
Correlate 500 responses with GPU driver and CUDA runtime errors to identify engine-crash events.
Alert on vLLM pods or processes that transition from healthy to permanently failing without a corresponding deployment event.

Monitoring Recommendations

Track per-tenant error rates on the /v1/completions and /v1/chat/completions endpoints and alert on sudden sustained failures.
Monitor GPU driver logs (dmesg, nvidia-smi events) for CUDA assertion failures tied to the vLLM process.
Capture and retain the request body for failed inference calls to support post-incident analysis of malicious payloads.

How to Mitigate CVE-2026-100654

Immediate Actions Required

Upgrade vLLM to version 0.29.0 or later on all inference nodes.
Place a validating reverse proxy or API gateway in front of vLLM to reject requests whose stop_token_ids exceed the model vocabulary size.
Restrict API credentials to trusted tenants and rotate keys for any accounts that may have been shared broadly.
Configure process supervision so the vLLM service restarts automatically when EngineCore enters a fatal state.

Patch Information

The maintainers fixed the issue in vLLM 0.29.0 by validating that each entry in stop_token_ids falls within the model vocabulary before the value is used as a logits index. Operators running earlier releases should upgrade to the fixed version. See the GitHub Security Advisory GHSA-v5gm-qgmv-gc6c for the full patch notes.

Workarounds

Strip or validate the stop_token_ids field at the API gateway before requests reach vLLM.
Reject requests that combine min_tokens > 0 with client-supplied stop_token_ids until the upgrade is applied.
Isolate inference workloads per tenant so a crash in one deployment does not affect shared capacity.

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__)"