Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessReach exposed vLLM API endpoint
-
DeliverySend request with multi-hundred-MB cache_salt
-
ExploitTrigger costly pickle + SHA-256 on scheduler thread
-
ExecutionStall single EngineCore thread
-
ImpactDeny service to all concurrent requests
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V2 - Validation and Business Logic Input validation, allowlisting
|
| Exploitation Conditions | Requires network reachability to a vLLM instance (before 0.29.0) that exposes the OpenAI-compatible or Anthropic-compatible API endpoints accepting the cache_salt parameter; no authentication is required (PR:N) and no user interaction (UI:N). Exploitation succeeds against default configurations because cache_salt lacks any maximum-length validation. The practical limiter is exposure: deployments that place vLLM behind an authenticating gateway, a reverse proxy enforcing request/body size limits, or on a private network are shielded, so real-world risk is concentrated on internet-facing or multi-tenant vLLM APIs without upstream size controls. |
| Impact | This is a real but availability-only issue with modest real-world priority. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N, VA:L, all other impacts N) confirms an unauthenticated, network, low-complexity attack whose only consequence is degraded availability - no confidentiality or integrity impact, no code execution, no data disclosure. No EPSS score, no CISA KEV listing, and no public POC were provided, so there is no signal of active or imminent exploitation; this reads as a defense-worthy hardening fix rather than an urgent, widely-exploited flaw. Note a signal tension worth flagging: the vendor rated availability as VA:L (Low), consistent with a transient per-request stall, yet the description states the single EngineCore scheduler thread stalls and denies service to ALL concurrent requests - a condition an attacker can trivially sustain by looping requests, which argues for a higher availability impact (I assess A:H for the sustained case). The overall 6.9 score is a reasonable medium; treat as patch-on-schedule for exposed/unauthenticated vLLM deployments, higher urgency if the API is internet-facing without an auth proxy or request-size limits. |
| Exploit ScenarioDerived | An attacker who can reach a vLLM OpenAI-compatible or Anthropic-compatible endpoint sends an HTTP request containing a multi-hundred-megabyte cache_salt value. vLLM pickles and SHA-256 hashes the oversized salt on its single scheduler thread, stalling the EngineCore and blocking all other in-flight and incoming inference requests; repeating the request sustains the outage. No authentication, user interaction, or special client is required; no public exploit code was identified at time of analysis. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 26, 2026
Denial of service in vLLM releases before 0.29.0 allows unauthenticated remote attackers to stall the single EngineCore scheduler thread by sending HTTP requests with multi-hundred-megabyte cache_salt values to the OpenAI-compatible or Anthropic-compatible API endpoints. The oversized salt value is pickle-serialized and SHA-256 hashed on the scheduler thread, so a single request blocks scheduling and inference for all concurrent requests, degrading or halting service. No public exploit code was identified at time of analysis and the issue is not in CISA KEV, so real-world risk is concentrated on internet-facing or multi-tenant vLLM deployments that expose these endpoints without an authenticating gateway or upstream request-size limits.
RemediationAI
Vendor-released patch: upgrade to vLLM 0.29.0 or later, which adds the missing maximum-length validation for cache_salt; the advisory at https://github.com/vllm-project/vllm/security/advisories/GHSA-wpww-v874-ph2p and the VulnCheck advisory at https://www.vulncheck.com/advisories/vllm-before-0.29.0-cpu-exhaustion-via-unbounded-cache-salt should be consulted for the exact fixed release. Until upgrading is possible, the most effective compensating control is to cap HTTP request/body size at the front end - e.g. nginx client_max_body_size or an equivalent Envoy/Istio max-request-bytes or API-gateway limit well below the hundreds-of-megabytes range - with the trade-off that legitimate requests carrying large prompts or oversized JSON payloads will be rejected, so the limit must be tuned to real workload sizes (cache_salt itself is normally a short token). Placing an authenticating gateway or mTLS in front of the OpenAI-compatible and Anthropic endpoints reduces the exposed population, but note the flaw is triggered before any application-level authentication and is not mitigated by auth alone, so it must be combined with body-size limits; additionally, restricting these endpoints to private networks or trusted tenants removes the untrusted-input path entirely at the cost of losing public API availability. Because the bottleneck is the single EngineCore scheduler thread, horizontal scaling or load balancing does not mitigate a single sustained attack but does limit the blast radius across replicas.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
vLLM accepts a cache_salt parameter on its OpenAI-compatible and Anthropic-compatible API endpoints, used to namespace/segregate prefix-cache (KV-cache) blocks between tenants when prefix caching is enabled. The root cause is CWE-20 (Improper Input Validation): the field is parsed and processed without any maximum-length check, and that processing happens on the single-threaded EngineCore scheduler loop, where the value undergoes pickle serialization and SHA-256 hashing. Because both operations scale with input size and the scheduler thread is a serialization point for the whole engine, an attacker-supplied salt of hundreds of megabytes turns a cheap HTTP request into a long CPU-bound stall that halts scheduling for every other request. The affected product is identified by CPE cpe:2.3:a:vllm-project:vllm:*:*:*:*:*:*:*:* for all versions below 0.29.0. One source tag labels this finding 'Information Disclosure', which does not match the described mechanism; the independent assessment treats the impact as availability-only (CVSS:3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H; vendor-scored CVSS:4.0 6.9 with VC:N/VI:N/VA:L), and this analysis follows the availability-only characterization. The unpatched state requires network reachability to an exposed API endpoint; per the CVSS vectors PR:N applies, so no authentication is required, and UI:N means no user interaction is needed.
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:L/SC:N/SI:N/SA:N
Unauthenticated network request with no interaction (AV:N/AC:L/PR:N/UI:N) stalls the single scheduler thread and can be sustained to deny all service, so A:H; no confidentiality or integrity impact.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
Lifecycle Timeline
1DescriptionCVE.org
vLLM versions before 0.29.0 contain a denial-of-service vulnerability in the cache_salt parameter accepted on OpenAI-compatible and Anthropic API endpoints, which lacks maximum length validation and is processed on the single EngineCore scheduler thread. Unauthenticated attackers can send HTTP requests with multi-hundred-megabyte salt values that trigger expensive pickle serialization and SHA-256 hashing, stalling the scheduler thread and denying service to all concurrent requests.
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
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-87741
GHSA-hm89-h84f-px3x
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB