Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessReach vLLM HTTP API over network
-
DeliveryPOST negative token ID to /v1/embeddings or /pooling
-
ExploitValue bypasses missing lower-bound check
-
ExecutionCUDA device-side assertion fires
-
PersistGPU context poisoned
-
ImpactAll subsequent inference requests fail until restart
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V2 - Validation and Business Logic Array index validation
|
| Exploitation Conditions | Exploitation requires network reachability to a vLLM instance (before 0.28.0) that exposes the /v1/embeddings or /pooling endpoints - these are part of vLLM's OpenAI-compatible HTTP server. No authentication, credentials, or user interaction is needed (PR:N/UI:N), and default configurations are affected since the vulnerable endpoints ship enabled. The single limiting factor is network exposure: vLLM has no built-in authentication, so risk hinges on whether the API is reachable by untrusted clients (public internet or shared internal network) versus isolated behind a gateway or private VPC. Impact is confined to availability - the poisoned GPU context denies service to all clients until an operator restarts the process - with no confidentiality or integrity consequence. |
| Impact | This is a genuine, high-credibility availability threat. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VA:H) describes a network-reachable, low-complexity, unauthenticated attack requiring no user interaction and yielding high impact on availability only (VC:N/VI:N) - fully consistent with the description of a single crafted request crashing the inference engine. The 8.7 score is driven entirely by the ease-of-exploitation metrics plus a persistent DoS: because the CUDA device-side assertion poisons the GPU context, the outage is not transient but lasts until an operator restarts the process, amplifying real-world impact. Signals are consistent rather than conflicting: no EPSS score, no CISA KEV listing, and no explicit weaponized POC flag are present in the input, so there is no evidence of active exploitation - but the advisory-level detail (negative token ID on named endpoints) makes the trigger trivial to reproduce. Net: a real priority for anyone exposing vLLM's HTTP API on an untrusted network, tempered by the fact that impact is DoS-only (no confidentiality or integrity loss) and many deployments sit behind internal gateways. The vendor's 8.7 slightly outweighs a strict CVSS 3.1 mapping (~7.5), reflecting the persistent nature of the crash. |
| Exploit ScenarioDerived | An attacker with network access to a vLLM server's HTTP API sends a single POST request to /v1/embeddings or /pooling containing a negative token ID. The missing lower-bound validation lets that value reach CUDA, triggering a device-side assertion that poisons the GPU context so every subsequent inference request fails until the process is manually restarted. No authentication, credentials, or user interaction is required, and the trigger is described in the public VulnCheck/GHSA advisories, making reproduction straightforward. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 18, 2026
Denial of service in vLLM before 0.28.0 allows an unauthenticated remote attacker to poison the process's GPU context by sending a single request containing a negative token ID to the /v1/embeddings or /pooling endpoints, after which all subsequent inference requests fail until the server is restarted. The vulnerable endpoints are part of vLLM's OpenAI-compatible HTTP server and ship enabled in default configurations, and because vLLM provides no built-in authentication, the practical risk is governed entirely by whether the API is reachable by untrusted clients over a public or shared network. Impact is availability-only (assessed CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H; vendor CVSS 8.7), no public exploit code was identified at time of analysis, and no KEV-listed active exploitation is reported.
RemediationAI
Vendor-released patch: upgrade to vLLM 0.28.0 or later, which is the first release outside the affected range (<0.28.0) per the vendor advisory and EUVD data, and confirm the fix by verifying that negative token IDs are rejected by /v1/embeddings and /pooling. Where immediate upgrading is not possible, place the vLLM HTTP server behind an authenticating reverse proxy or API gateway and reject requests whose token ID arrays contain negative values (input validation at the edge is the cheapest compensating control, though it adds a parsing layer and must be kept in sync with request schemas), or disable the /v1/embeddings and /pooling routes if embedding and pooling workloads are not required - the trade-off being loss of that functionality for legitimate clients. Restricting network access so only trusted internal services can reach the API (private VPC, firewall allow-lists, no public ingress) removes the exposure entirely but requires re-architecting any existing public-facing deployment, and deploying vLLM in a process-supervised configuration that automatically restarts the engine on failure shortens the outage window at the cost of dropped in-flight requests. There is no server-side configuration flag documented as a token-ID bounds check prior to 0.28.0, so upstream patching combined with network restriction is the only durable mitigation; see https://github.com/vllm-project/vllm/security/advisories/GHSA-25q3-v2hm-8vpf and https://www.vulncheck.com/advisories/vllm-before-0.28.0-denial-of-service-via-negative-token-id for the authoritative fix guidance.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in pypi
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The root cause is CWE-129 (Improper Validation of Array Index): vLLM's request parsing for /v1/embeddings and /pooling validates that token IDs are integers but does not validate the lower bound, so a negative token ID is accepted and passed down into the embedding/pooling kernel path where it is used as an index. Token IDs are intended to be non-negative offsets into token/embedding tables, so a negative value becomes an out-of-bounds GPU memory access that trips a CUDA device-side assertion. The critical consequence is that CUDA device-side assertions are context-fatal: the CUDA context for that process is poisoned, not merely the failing request, so the engine cannot serve any further requests until an operator restarts the process. The affected component is vLLM's OpenAI-compatible HTTP server, whose /v1/embeddings and /pooling routes are the entry points; the CPE cpe:2.3:a:vllm-project:vllm:*:*:*:*:*:*:*:* covers the vllm-project/vllm distribution generically, with the EUVD data pinning the vulnerable range to vllm 0 through versions below 0.28.0. Because vLLM has no native authentication layer, exploitation requires only network reachability to those routes (PR:N/UI:N), and because batch scheduling forwards client-supplied token IDs directly to the GPU, a single small request is sufficient to take down a multi-tenant deployment.
Know when Vllm gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Network-reachable, low-complexity, unauthenticated single request with no user interaction; impact is a persistent engine crash so A:H with C:N/I:N.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
Lifecycle Timeline
2DescriptionCVE.org
vLLM versions before 0.28.0 fail to validate the lower bound of token IDs in the /v1/embeddings and /pooling endpoints, allowing unauthenticated attackers to crash the engine by submitting negative token IDs. A single request with a negative token ID triggers a CUDA device-side assertion that poisons the GPU context, causing all subsequent requests to fail until the process restarts.
Blast Radius
ecosystem impact- 2 pypi packages depend on vllm (2 direct, 0 indirect)
Ecosystem-wide dependent count for version 0.28.0.
Technical POC Analysis
Note on identifiers: the supplied GitHub advisory (GHSA-25q3-v2hm-8vpf) is filed under "No known CVE" and "No CWEs", with a CVSS v3 score of 7.5/High.
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
A high-severity flaw in vLLM's OpenAI-compatible inference server (versions prior to 0.28.0) lets any unauthenticated client disable the entire model-serving process with a single malformed request, forcing a manual restart before any further inference can succeed. Because the affected endpoints ship enabled by default and vLLM provides no built-in authentication, any organization exposing these services to untrusted or shared networks is effectively granting anonymous users a one-request kill switch against its AI workloads. Leadership should care because the impact is immediate and total loss of availability for a production inference service, with no data compromise but potentially significant service disruption and recovery costs.
Apply vendor patch.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Rated critical severity (CVSS 10.0
vllm-project vllm version v0.6.2 contains a vulnerability in the MessageQueue.dequeue() API function. Rated critical sev
Information exposure in vLLM inference engine versions 0.8.3 to before 0.14.1. Invalid image requests to the multimodal
Timing-based API key recovery in vLLM before 0.11.0rc2 can let remote attackers bypass bearer-token authentication on de
vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Rated high severity (CVSS 7.5), th
Denial of service in the vLLM LLM inference server (all versions prior to 0.24.0) allows a remote client to crash the sh
vLLM before version 0.14.1 contains a server-side request forgery vulnerability in the MediaConnector class where incons
Out-of-memory worker crashes in vLLM can be induced by a single small compressed audio payload submitted to the /v1/chat
vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Rated medium severity (CVSS 6.5),
GPU memory exhaustion in vLLM versions prior to 0.28.0 lets an attacker with low-privileged API access (PR:L in the CVSS
Multimodal inference requests to vLLM deployments running versions prior to 0.28.0 can trigger a process-level assertion
Uncontrolled resource consumption in vLLM's OpenAI-compatible completions endpoint allows any authenticated API client t
EUVD-2026-82911
GHSA-c3vq-r33v-49cr
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB