CVE-2026-116181: vLLM: invalid stop_token_ids crash engine, GPU OOB write

MEDIUM

Published October 25, 2026

CISO Take

vLLM versions 0.20.1 up to (but not including) 0.29.0 fail to validate stop_token_ids, so any authenticated API user can submit out-of-vocabulary token IDs through OpenAI-compatible chat, completion, generate, or batch endpoints and crash the inference engine or trigger an out-of-bounds write in the V2 runner's logits buffer. The CVSS score of 6.5 reflects availability impact only, but a single low-privilege request can take down a shared GPU serving tier, and the out-of-bounds write adds memory-corruption risk that the score does not capture. There is no EPSS data, no known public exploit, no Nuclei template and no KEV listing, so exploitation is not currently observed, but the trigger is trivial for anyone holding an API key. Upgrade to vLLM 0.29.0 or later, and until then validate or strip stop_token_ids at your API gateway and restrict inference endpoint access to trusted tenants.

Sources:NVDGitHub AdvisoryATLASvulncheck.com

What is the risk?

Medium overall (CVSS 6.5, AV:N/AC:L/PR:L/UI:N). Exploitation is trivial for any user with valid API access: one malformed request is enough. Likelihood is raised for multi-tenant or internet-exposed vLLM deployments, and lowered where the endpoint is internal and tightly authenticated. No EPSS score, public exploit, scanner template or KEV listing exists as of publication, so active exploitation is unconfirmed. The GPU out-of-bounds write could potentially have integrity or confidentiality implications beyond the rated availability impact, but the vendor and NVD rate only availability (A:H).

How does the attack unfold?

Initial Access

Attacker obtains a low-privilege API key or access to a reachable vLLM OpenAI-compatible endpoint.

AML.T0040

Exploitation

Attacker sends a chat, completion, generate or batch request with out-of-vocabulary stop_token_ids that bypasses validation.

AML.T0049

Impact

The engine crashes or writes outside the V2 runner's logits buffer, taking down the inference service and dropping in-flight requests.

AML.T0029

Initial Access

Attacker obtains a low-privilege API key or access to a reachable vLLM OpenAI-compatible endpoint.

AML.T0040

Exploitation

Attacker sends a chat, completion, generate or batch request with out-of-vocabulary stop_token_ids that bypasses validation.

AML.T0049

Impact

The engine crashes or writes outside the V2 runner's logits buffer, taking down the inference service and dropping in-flight requests.

AML.T0029

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
vLLM	pip	—	No patch
95.4K94 dependentsPushed 6d ago27% patched~37d to patchFull package profile →

Do you use vLLM? You're affected.

How severe is it?

CVSS 3.1

6.5 / 10

EPSS

0.4%

chance of exploitation in 30 days

Higher than 31% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AVNetwork

ACLow

PRLow

UINone

SUnchanged

CNone

INone

AHigh

What should I do?

1 step

1) Upgrade vLLM to 0.29.0 or later. 2) Until patched, validate request parameters at an API gateway or proxy: reject or strip stop_token_ids containing values outside the served model's vocabulary range (negative or >= vocab size). 3) Restrict access to the inference API to trusted, authenticated clients; apply per-key rate limiting and avoid exposing vLLM directly to the internet. 4) Run vLLM under a supervisor with auto-restart and health checks to limit downtime, and separate tenants onto different instances where feasible. 5) Detection: alert on repeated engine crashes or restarts, CUDA errors or illegal memory access messages in logs, and requests whose payload includes stop_token_ids, correlated to the API key that sent them. 6) Review the GHSA-w9r6-29q4-pvpr advisory for further guidance.

How is it classified?

DoSInferenceAPIAML.T0029- Denial of AI Service 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-Procedures to respond to and recover from unknown risks

OWASP LLM Top 10

LLM10:2025-Unbounded Consumption

Frequently Asked Questions

What is CVE-2026-116181?

Is CVE-2026-116181 actively exploited?

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

How to fix CVE-2026-116181?

1) Upgrade vLLM to 0.29.0 or later. 2) Until patched, validate request parameters at an API gateway or proxy: reject or strip stop_token_ids containing values outside the served model's vocabulary range (negative or >= vocab size). 3) Restrict access to the inference API to trusted, authenticated clients; apply per-key rate limiting and avoid exposing vLLM directly to the internet. 4) Run vLLM under a supervisor with auto-restart and health checks to limit downtime, and separate tenants onto different instances where feasible. 5) Detection: alert on repeated engine crashes or restarts, CUDA errors or illegal memory access messages in logs, and requests whose payload includes stop_token_ids, correlated to the API key that sent them. 6) Review the GHSA-w9r6-29q4-pvpr advisory for further guidance.

What systems are affected by CVE-2026-116181?

This vulnerability affects the following AI/ML architecture patterns: Model serving, LLM inference APIs, Multi-tenant inference gateways, Batch inference pipelines, RAG backends, Agent frameworks using vLLM backends.

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

CVE-2026-116181 has a CVSS v3.1 base score of 6.5 (MEDIUM). The EPSS exploitation probability is 0.37%.

What is the AI security impact?

Affected AI Architectures

Model servingLLM inference APIsMulti-tenant inference gatewaysBatch inference pipelinesRAG backendsAgent frameworks using vLLM backends

MITRE ATLAS Techniques

AML.T0029Denial of AI Service

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: LLM10:2025

What are the technical details?

Original Advisory

vLLM from 0.20.1 before 0.29.0 contains an improper input validation vulnerability that allows remote attackers to crash the engine by supplying out-of-vocabulary stop_token_ids. Attackers can send OpenAI chat, completion, generate, or batch requests with invalid IDs to terminate the engine or write outside the V2 runner's logits buffer.

Exploitation Scenario

An attacker obtains a low-privilege API key for a company's internal LLM gateway backed by vLLM, for example through a free-tier signup or a leaked key. They send an OpenAI-compatible chat completion request that includes stop_token_ids with a value far larger than the model's vocabulary size. The server accepts the unvalidated IDs, and the engine either crashes or writes outside the logits buffer on the GPU. The attacker repeats the request each time the service restarts, producing a sustained denial of service across every application that shares the serving cluster.

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.