AI Threat AlertCVE-2026-94625: vLLM: Mooncake placeholder leak enables slow DoS
MEDIUMCVE-2026-94625 is a resource exhaustion flaw in vLLM's MooncakeConnector, used for disaggregated prefill/decode KV-cache transfer. Rejected prefill requests leave ownerless transfer placeholders that are never reclaimed, so an unauthenticated network attacker can fill the sender task pool and delay valid requests by up to 480 seconds. Health checks keep returning success throughout, so load balancers and monitors will not detect the degradation or fail over. Risk is moderate: CVSS 5.3, EPSS 0.5% (58th percentile), not in CISA KEV, no public exploit or Nuclei template, and CISA SSVC says TRACK. Exposure is limited to deployments that use the Mooncake KV connector in disaggregated serving. Upgrade to a vLLM release containing the fix from PR #51236 (versions after 0.29.0), add latency-based SLO alerting on the inference path instead of relying on health checks, and restrict network access to prefill endpoints.
What is the risk?
Medium overall. The attack is network-reachable, needs no privileges or user interaction, and has low complexity, but it affects availability only (A:L) with no confidentiality or integrity impact. Only deployments using MooncakeConnector for disaggregated prefill/decode are exposed, which narrows the population. No public exploit, no KEV listing and low EPSS keep near-term exploitation likelihood low. The main risk multiplier is that health checks stay green during degradation, which delays detection and defeats automatic failover.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| vLLM | pip | — | No patch |
Do you use vLLM? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 step1) Upgrade vLLM to a release that includes the fix from PR #51236 (any release after 0.29.0 containing it); verify against the vendor advisory. 2) If patching is delayed, disable MooncakeConnector or use a different KV connector, or restrict prefill endpoints to trusted internal networks and the decode tier only. 3) Place authentication, rate limiting and request validation in front of the inference gateway so malformed or rejected requests cannot be sent in bulk. 4) Replace shallow health checks with synthetic inference probes and alert on p95/p99 time-to-first-token and queue depth. 5) Monitor sender task pool utilization and rejected-request rates, and schedule rolling restarts of prefill workers as a stopgap to reclaim leaked placeholders.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-94625?
CVE-2026-94625 is a resource exhaustion flaw in vLLM's MooncakeConnector, used for disaggregated prefill/decode KV-cache transfer. Rejected prefill requests leave ownerless transfer placeholders that are never reclaimed, so an unauthenticated network attacker can fill the sender task pool and delay valid requests by up to 480 seconds. Health checks keep returning success throughout, so load balancers and monitors will not detect the degradation or fail over. Risk is moderate: CVSS 5.3, EPSS 0.5% (58th percentile), not in CISA KEV, no public exploit or Nuclei template, and CISA SSVC says TRACK. Exposure is limited to deployments that use the Mooncake KV connector in disaggregated serving. Upgrade to a vLLM release containing the fix from PR #51236 (versions after 0.29.0), add latency-based SLO alerting on the inference path instead of relying on health checks, and restrict network access to prefill endpoints.
Is CVE-2026-94625 actively exploited?
No confirmed active exploitation of CVE-2026-94625 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-94625?
1) Upgrade vLLM to a release that includes the fix from PR #51236 (any release after 0.29.0 containing it); verify against the vendor advisory. 2) If patching is delayed, disable MooncakeConnector or use a different KV connector, or restrict prefill endpoints to trusted internal networks and the decode tier only. 3) Place authentication, rate limiting and request validation in front of the inference gateway so malformed or rejected requests cannot be sent in bulk. 4) Replace shallow health checks with synthetic inference probes and alert on p95/p99 time-to-first-token and queue depth. 5) Monitor sender task pool utilization and rejected-request rates, and schedule rolling restarts of prefill workers as a stopgap to reclaim leaked placeholders.
What systems are affected by CVE-2026-94625?
This vulnerability affects the following AI/ML architecture patterns: LLM model serving, disaggregated prefill/decode inference, KV-cache transfer pipelines, GPU inference clusters.
What is the CVSS score for CVE-2026-94625?
CVE-2026-94625 has a CVSS v3.1 base score of 5.3 (MEDIUM). The EPSS exploitation probability is 0.52%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0029Denial of AI ServiceAML.T0040AI Model Inference API AccessAML.T0049Exploit Public-Facing ApplicationCompliance Controls Affected
What are the technical details?
Original Advisory
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.
Exploitation Scenario
An attacker finds an exposed vLLM prefill endpoint in a disaggregated deployment using Mooncake. They repeatedly submit requests crafted to be rejected, such as oversized or invalid ones. Each rejection leaves an ownerless transfer placeholder that is never freed. After enough requests the sender task pool is exhausted, and legitimate prefill requests wait up to 480 seconds. The service looks healthy to load balancers, so operators see only user complaints and timeouts while the attacker keeps costs low.
Weaknesses (CWE)
CWE-772Missing Release of Resource after Effective LifetimePrimaryCWE-772Missing Release of Resource after Effective LifetimeCWE-772 — Missing Release of Resource after Effective Lifetime: The product does not release a resource after its effective lifetime has ended, i.e., after the resource is no longer needed.
- [Requirements] Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, languages such as Java, Ruby, and Lisp perform automatic garbage collection that releases memory for objects that have been deallocated.
- [Implementation] It is good practice to be responsible for freeing all resources you allocate and to be consistent with how and where you free resources in a function. If you allocate resources that you intend to free upon completion of the function, you must be sure to free the resources at all exit points for that function including error conditions.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:LReferences
Timeline
Related Vulnerabilities
CVE-2026-6173210.0Decepticon: ChatML token injection yields sandbox RCE
Same package: vllmCVE-2024-110419.8vllm: RCE via unsafe pickle deserialization in MessageQueue
Same package: vllmCVE-2026-259609.8vllm: SSRF allows internal network access
Same package: vllmCVE-2025-472779.8vLLM: RCE via exposed TCPStore in distributed inference
Same package: vllmCVE-2024-90539.8vllm: RCE via unsafe pickle deserialization in RPC server
Same package: vllm