EUVD-2026-82534
GHSA-jh5x-pggf-m4cr
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessReach vLLM inference API over network
-
DeliverySubmit requests with max_tokens=0
-
ExploitTrigger orphaned decode-side metadata leak
-
ExecutionRepeat to accumulate unbounded memory
-
ImpactExhaust decode-worker memory forcing restart (DoS)
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Resource cleanup, leak prevention
|
| Exploitation Conditions | Requires the target to run vLLM in prefill/decode (P/D) disaggregated serving mode using the NIXL KV connector - this is the specific non-default deployment where decode-side recv metadata is tracked and leaked; standard single-instance vLLM serving is not affected. Given that mode, exploitation is remote and unauthenticated (PR:N/UI:N/AC:L): the attacker only needs network reach to the inference endpoint and sends requests with max_tokens=0, which are rejected/aborted before scheduling and leave metadata in _recving_metadata that is never popped. The primary limiting factor is the disaggregated-deployment prerequisite; impact is bounded to availability (worker memory exhaustion and restart) with no data disclosure or code execution. |
| Impact | This is a genuine but bounded availability issue, not a critical multi-impact flaw. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H) is internally consistent with the description: pure availability impact (VA:H) via unbounded decode-worker memory growth, with no confidentiality or integrity impact - which directly contradicts the input Tag of 'Information Disclosure' (VC:N/VI:N confirm no data exposure). CWE-401 (memory leak) matches the root cause: decode-side metadata for rejected/aborted requests is never cleaned from _recving_metadata. No EPSS score, KEV listing, or public exploit is present in the input, so exploitation status is 'no public exploit identified at time of analysis'; the vendor advisory (VulnCheck) and merged fix PR #55677 with regression tests confirm the mechanism is real and reproducible, which lowers the barrier to weaponization even without a packaged PoC. The 8.7 score is availability-only and is materially gated by a non-default deployment mode (prefill/decode disaggregation via the NIXL KV connector), so real-world priority is moderate: high for operators actually running disaggregated P/D serving, low for the majority of vLLM users on standard single-node serving. Net: treat as a targeted DoS risk for disaggregated deployments, not a widespread critical. |
| Exploit ScenarioDerived | An operator runs vLLM in prefill/decode disaggregated mode (NIXL KV connector). A remote unauthenticated attacker repeatedly submits inference requests with max_tokens=0; each rejected request leaves orphaned decode-side metadata that is never reclaimed, so worker memory climbs without bound until the decode worker exhausts memory and restarts. No public PoC is provided, but the merged fix PR #55677 includes regression tests that precisely demonstrate the accumulation path. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 17, 2026
vLLM 0.29.0 and earlier leak decode-side receive metadata for inference requests that are rejected or aborted before scheduling, allowing a remote attacker who can reach the inference endpoint to grow decode-worker memory without bound by repeatedly submitting requests with max_tokens=0 until the worker restarts. The flaw only manifests in prefill/decode (P/D) disaggregated serving deployments that use the NIXL KV connector, so standard monolithic vLLM serving is unaffected. Impact is availability-only (worker memory exhaustion and restart) with no data disclosure or code execution; no public exploit code has been identified at time of analysis and the CVE is not in CISA KEV, though the condition is trivially triggerable once the disaggregated deployment prerequisite is met.
RemediationAI
Upstream fix available (PR/commit); released patched version not independently confirmed - the corrective changes are in https://github.com/vllm-project/vllm/pull/55677, which stops notify-only empty recvs from persisting in _recving_metadata and adds regression tests, so operators should upgrade to the first tagged vLLM release that contains PR 55677 rather than assuming 0.29.0 is safe. Until that release is deployed, the most effective compensating control is to avoid the affected deployment shape entirely: run vLLM in monolithic (non-disaggregated) serving mode, or switch the disaggregated deployment to a KV connector other than NIXL, at the cost of losing the throughput and topology benefits of NIXL-based P/D disaggregation. If P/D disaggregation with NIXL must remain in service, terminate the decode worker endpoint behind an authenticated gateway or network ACL so only trusted clients have reach (the flaw is unauthenticated but does require network access to the inference API), and reject or normalize requests carrying max_tokens=0 at that gateway before they reach the scheduler - this blocks the specific trigger but would also break legitimate zero-token/probe-style requests if your clients rely on them. Additionally, monitor decode-worker RSS/heap growth and configure restarts or memory ceilings so that a leak-driven OOM triggers a controlled restart instead of an unplanned outage; this contains but does not eliminate the leak. Full mitigation requires the patched upstream release.
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 issue lives in vLLM's KV-cache transfer layer, specifically the NIXL connector used to move KV blocks between prefill and decode workers in disaggregated serving (vllm/distributed/kv_transfer/kv_connector/v1/nixl/push_worker.py, lines 162-181). The decode-side worker maintains bookkeeping dictionaries such as _recving_metadata and _recving_transfers, keyed by request ID, to track in-flight receive operations whose completion is signalled by a producer WRITE; entries are normally popped in get_finished once the transfer completes. When a decode-side request is aborted or rejected before scheduling (for example, a request whose max_tokens=0 is rejected upstream), the decode worker still enqueues an 'empty recv' with no local block IDs. Because no WRITE will ever complete for such a request, the corresponding metadata entry is never popped, and repeated empty recvs accumulate monotonically in worker memory. The root cause is CWE-401 (Missing Release of Memory after Effective Lifetime) - a per-request resource that is allocated and never released - rather than an unbounded buffer overflow or deserialization flaw. The upstream fix in PR 55677 changes start_load_kv/_read_blocks so that notify-only empty recvs are not persisted in _recving_metadata, and also ensures an aborted D-side request still enqueues an empty recv to release the prefiller while consuming do_remote_prefill so the recv is not re-issued; the accompanying regression tests explicitly assert that repeated empty recvs do not grow metadata while genuine non-empty recvs continue to be tracked.
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
Remote unauthenticated request flooding (AV:N/AC:L/PR:N/UI:N) causes only memory-exhaustion DoS, so C:N/I:N/A:H; scope unchanged as impact stays within the vLLM worker.
Primary rating from Vendor (vulncheck).
CVSS VectorVendor: vulncheck
DescriptionCVE.org
vLLM through 0.29.0 fails to properly clean up decode-side metadata for rejected inference requests in prefill/decode disaggregated deployments. Remote attackers can submit requests with max_tokens=0 to exhaust decode-worker memory without bound until the worker restarts.
Blast Radius
ecosystem impact- 4 pypi packages depend on vllm (4 direct, 0 indirect)
Ecosystem-wide dependent count for version 0.30.0.
Executive ViewAI
A memory-exhaustion flaw in vLLM 0.29.0 and earlier affects only deployments that split inference into separate prefill and decode stages using the NIXL KV connector, allowing a remote party who can reach the inference endpoint to force repeated decode-worker restarts and degrade or interrupt model serving. Monolithic vLLM deployments are unaffected, so exposure is confined to organizations running that specific disaggregated architecture, where the practical consequence is service availability rather than data loss or system compromise. Because a vendor patch is not yet available, leadership should treat this as an operational resilience issue for the teams owning those endpoints until containment and remediation are complete.
No vendor-released patch identified at time of analysis. Interim mitigations: restrict network access to inference endpoints to trusted clients; enforce per-client request-rate and concurrency caps; reject or block requests with max_tokens=0 at the gateway or front-end proxy; monitor decode-worker memory growth and restart events and apply memory limits with auto-restart; if containment is not achievable, temporarily revert to monolithic vLLM serving or take the P/D disaggregated deployment using the NIXL KV connector offline.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
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
Exploit-DB