Skip to main content

vLLM MooncakeConnector EUVDEUVD-2026-84219

| CVE-2026-94625 MEDIUM
Missing Release of Resource after Effective Lifetime (CWE-772)
2026-09-21 disclosure@vulncheck.com GHSA-9p52-m77h-4wq5
6.9
CVSS 4.0 · Vendor: vulncheck
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Reach vLLM Mooncake endpoint (AV:N, PR:N)
  2. Delivery
    Send prefill request rejected pre-admission
  3. Exploit
    Prefiller creates ownerless transfer placeholder
  4. Execution
    Placeholder never reclaimed, sender task held
  5. Persist
    Repeat to exhaust sender task pools
  6. Impact
    Valid requests delayed ~480s while health checks pass

Vulnerability Assessment

Weakness
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Resource cleanup on lifecycle end
Exploitation Conditions

Requires the target to run vLLM (through 0.29.0) configured for disaggregated prefill/decode with the MooncakeConnector KV-transfer backend (kv_producer/kv_consumer roles) - this is a non-default, specialized topology, not a standard single-node vLLM serve. Given that configuration, exploitation is remote and unauthenticated (AV:N/PR:N/UI:N): the attacker only needs network access to submit prefill requests that get rejected before engine admission, triggering ownerless placeholders. Limiting factors: the non-default connector requirement is the primary constraint; impact is bounded to availability degradation (delays up to ~480 seconds and sender-pool exhaustion) rather than crash or data compromise, and the silent nature (health checks still succeed) affects detection rather than exploitability.

Impact

Signals converge on a genuine but bounded availability issue, not a top-tier priority. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L, 6.9) confirms remote unauthenticated exploitation with LOW availability impact only - no confidentiality or integrity effect, consistent with CWE-772 (missing release of resource). No EPSS score, no CISA KEV listing, and no standalone proof-of-concept were provided (the referenced PR #51236 is the fix diff plus regression tests, not exploit code), so this is 'no public exploit identified at time of analysis.' The most under-appreciated risk factor is the description's note that health checks keep returning success while valid requests are delayed up to 480 seconds - meaning the degradation is silent and could evade standard liveness monitoring. Balancing against that: exploitation is gated on a non-default deployment topology (disaggregated prefill/decode using MooncakeConnector), which sharply narrows the real exposed population despite vLLM's broad footprint. Net: a real, low-effort DoS worth patching for anyone running the affected connector, but not an emergency for the majority of vLLM operators who do not use Mooncake KV transfer.

Exploit ScenarioDerived

An attacker with network reach to a vLLM decode/proxy endpoint repeatedly submits prefill requests crafted to be rejected before engine admission; each one causes the prefiller to create an ownerless transfer placeholder that is never reclaimed. Sustained flooding exhausts the sender task pools so legitimate inference requests stall for up to ~480 seconds, while health checks continue reporting the service as healthy. No public exploit code exists - only the upstream fix PR and its regression tests.

This Month Plan within 30 days. Why: MEDIUM severity (CVSS 4.0-6.9).
Patch available 0.3% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Sep 21, 2026

Denial of service in vLLM through 0.29.0 allows remote, unauthenticated attackers to exhaust the Mooncake connector's sender task pool by submitting prefill requests that are rejected before engine admission, causing legitimate KV-cache transfers to be delayed by up to roughly 480 seconds while the service's health checks keep reporting success. The issue only affects deployments running disaggregated prefill/decode with the MooncakeConnector KV-transfer backend (kv_producer/kv_consumer roles), which is a specialized, non-default topology rather than a standard single-node vLLM serve; a standard vLLM installation is not exposed. There is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis - the VulnCheck advisory and an upstream GitHub pull request (PR #51236) that adds an orphan-transfer timeout constitute the primary public signals, and impact is bounded to availability degradation rather than crash, data disclosure, or code execution.

RemediationAI

Upstream fix available (PR/commit); released patched version not independently confirmed - apply the change from https://github.com/vllm-project/vllm/pull/51236, which reclaims ownerless prefill placeholders via a new VLLM_MOONCAKE_ORPHAN_TRANSFER_TIMEOUT setting (documented default 60 seconds) and releases the sender task with a FINISH-status timeout response. Because no fixed release tag is confirmed in the supplied data, track vLLM releases after 0.29.0 and pin to the first version that contains this PR. If immediate upgrade is not possible, compensating controls should focus on the exposed transfer surface: restrict network reachability of the Mooncake/disaggregated prefill and decode endpoints to trusted decoder/engine peers only (firewall or mTLS between nodes), which closes the remote, unauthenticated attack path but will break multi-tenant or cross-cluster topologies that legitimately traverse untrusted networks; alternatively deploy an authenticating proxy in front of the prefill submission path to reject untrusted request sources, at the cost of added latency and a new component to operate. Since liveness/health checks still return success during the exhaustion window, add monitoring on sender task pool occupancy and on request latency approaching the ~480-second ceiling (rather than relying on health endpoints), and consider dropping the orphan timeout below the 60-second default for latency-sensitive clusters - though setting it too low risks discarding legitimate in-flight transfers under load. Consult the VulnCheck advisory at https://www.vulncheck.com/advisories/vllm-through-0.29.0-resource-exhaustion-via-ownerless-mooncake-transfer-placeholders and the upstream project at https://github.com/vllm-project/vllm for updates.

Affected VersionsENISA

vllm 0 ≤0.29.0

Affected Packages

pypi vllm fix: 0.30.0

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 flaw is CWE-772 (Missing Release of Resource after Effective Lifetime) in vLLM's MooncakeConnector, the KV-cache transfer connector used for disaggregated serving where prefiller and decoder instances run on separate nodes and exchange KV blocks over a Mooncake transport channel. In the vulnerable code path (v0.29.0, vllm/distributed/kv_transfer/kv_connector/v1/mooncake/mooncake_connector.py), when a decoder requests a transfer ID that the prefiller has not yet registered - for example because the originating request was rejected before engine admission - the prefiller allocates a SendBlockMeta placeholder with an empty producer request ID (p_req_id="") and waits for a claim. These ownerless placeholders have no owning request to drive their lifetime, so the normal timeout/cleanup path keyed on p_req_id never fires; they accumulate in the reqs_need_send map, consume entries in the sender task pool, and eventually starve valid transfers, which queue behind them for up to ~480 seconds. Because the process remains alive and responsive to liveness probes, orchestration health checks continue to return success, masking the degradation. The upstream fix adds an environment-controlled orphan expiry (VLLM_MOONCAKE_ORPHAN_TRANSFER_TIMEOUT, default 60 seconds) plus eviction logic in fetch_finished_sending_reqs() and an error response (FINISH status with err_reqs/Timeout message) when an unclaimed placeholder expires, releasing the sender task.

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

Vendor (vulncheck) PRIMARY 6.9 MEDIUM
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
vuln.today AI 5.3 MEDIUM

Remote unauthenticated flooding (AV:N/AC:L/PR:N/UI:N) with no confidentiality or integrity effect; impact is partial availability degradation (request delay/task-pool exhaustion), so A:L, not A:H.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
SUSE MEDIUM
Red Hat 7.5 HIGH

Primary rating from Vendor (vulncheck).

CVSS VectorVendor: vulncheck

Attack Vector
Network
Attack Complexity
Low
Attack Requirements
None
Privileges Required
None
User Interaction
None
Vulnerable system: Confidentiality
None
Vulnerable system: Integrity
None
Vulnerable system: Availability
Low
Subsequent system: Confidentiality
None
Subsequent system: Integrity
None
Subsequent system: Availability
None

DescriptionCVE.org

vLLM through 0.29.0 contains a resource exhaustion vulnerability in MooncakeConnector where rejected prefill requests create ownerless transfer placeholders that are never reclaimed. Attackers can send rejected requests to exhaust sender task pools, causing valid requests to be delayed by up to 480 seconds while health checks continue returning success.

Blast Radius

ecosystem impact
† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth
  • 3 pypi packages depend on vllm (3 direct, 0 indirect)

Ecosystem-wide dependent count for version 0.30.0.

Threat Intelligence Overview

EPSS Score
0.3%
Top 77% exploitable
Prevalence
High
vLLM is widely deployed LLM inference infra, though Mooncake connector is optional
Data Quality
7 sources
Confidence: High
EUVD 🇯🇵JVN NVD CVE.org EPSS Vulnrichment Vendor GitHub VulDB

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.

SignalValue
Severity MEDIUM
CISA KEV No
Public POC No
EPSS 0.3%
Patch available Yes
Active threat No
Deciding rule
MEDIUM severity (CVSS 4.0-6.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation
None
System Exposure· derived
Open
Automatable
Yes
Human Impact· derived
High
Technical Impact
Partial

Priority Score

34
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +34
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.

More in Vllm

View all
CVE-2025-32444 CRITICAL POC
10.0 Apr 30

vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Rated critical severity (CVSS 10.0

CVE-2024-11041 CRITICAL POC
9.8 Mar 20

vllm-project vllm version v0.6.2 contains a vulnerability in the MessageQueue.dequeue() API function. Rated critical sev

CVE-2026-22778 CRITICAL POC
9.8 Feb 02

Information exposure in vLLM inference engine versions 0.8.3 to before 0.14.1. Invalid image requests to the multimodal

CVE-2025-30202 HIGH POC
7.5 Apr 30

vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Rated high severity (CVSS 7.5), th

CVE-2026-24779 HIGH POC
7.1 Jan 27

vLLM before version 0.14.1 contains a server-side request forgery vulnerability in the MediaConnector class where incons

CVE-2026-57173 MEDIUM POC
6.5 Sep 16

Out-of-memory worker crashes in vLLM can be induced by a single small compressed audio payload submitted to the /v1/chat

CVE-2025-46560 MEDIUM POC
6.5 Apr 30

vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Rated medium severity (CVSS 6.5),

CVE-2026-69147 MEDIUM POC
6.5 Sep 16

GPU memory exhaustion in vLLM versions prior to 0.28.0 lets an attacker with low-privileged API access (PR:L in the CVSS

CVE-2026-105753 MEDIUM POC
6.5 Oct 05

Multimodal inference requests to vLLM deployments running versions prior to 0.28.0 can trigger a process-level assertion

CVE-2026-73559 MEDIUM POC
6.5 Aug 13

Uncontrolled resource consumption in vLLM's OpenAI-compatible completions endpoint allows any authenticated API client t

CVE-2026-22773 MEDIUM POC
6.5 Jan 10

Vllm versions up to 0.12.0 is affected by allocation of resources without limits or throttling (CVSS 6.5).

CVE-2026-73557 MEDIUM POC
6.3 Aug 13

Race condition in vLLM's prompt embedding loader allows concurrent API requests to bypass the sparse tensor invariant gu

Vendor StatusVendor

SUSE

Severity: Moderate

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy