CVE-2026-94627: vLLM Mooncake KV cache leak enables

CISO Take

vLLM's Mooncake connector, used in prefill/decode disaggregated deployments, fails to release GPU KV cache blocks when several child requests share one transfer ID. An unauthenticated remote attacker can send completion requests with multiple prompts and make orphaned blocks pile up until GPU memory is exhausted and legitimate requests stop executing. Only a process restart clears the leaked memory. Exploitation likelihood is low to moderate: EPSS is 0.00627 (top 52%), the CVE is not in CISA KEV, no public exploit or Nuclei template exists, and CISA SSVC says TRACK. The impact is availability only, with no confidentiality or integrity loss, but it hits expensive GPU capacity. Upgrade to a vLLM release that includes the fix from PR #49796 (versions after 0.29.0). Until then, put authentication and rate limiting in front of the inference API and alert on GPU memory growing steadily without a matching rise in load.

Sources:NVDEPSSCISA SSVCGitHub Advisoryvulncheck.comATLAS

What is the risk?

Risk is medium-high for exposed deployments and low for others. CVSS 7.5 reflects network reachability, low complexity, no privileges and no user interaction, with the impact limited to availability. Exploitation likelihood is low to moderate (EPSS 0.00627, no public exploit, not in KEV, SSVC TRACK). Exposure is limited to disaggregated prefill/decode setups that use the Mooncake KV transfer connector, which is a narrower population than all vLLM users. Where the endpoint is internet-facing or unauthenticated, the risk rises sharply because the attack needs only ordinary API calls.

How does the attack unfold?

Initial Access

Attacker reaches an exposed vLLM completions API in a Mooncake-based disaggregated deployment.

AML.T0049

Exploitation

Attacker sends completion requests with multiple prompts so child requests share one transfer ID and KV cache blocks are orphaned.

AML.T0040

Resource Exhaustion

Leaked KV cache blocks accumulate on the GPU until free memory runs out.

AML.T0034.001

Impact

Legitimate inference requests fail or stall until the process is restarted.

AML.T0029

Initial Access

Attacker reaches an exposed vLLM completions API in a Mooncake-based disaggregated deployment.

AML.T0049

Exploitation

Attacker sends completion requests with multiple prompts so child requests share one transfer ID and KV cache blocks are orphaned.

AML.T0040

Resource Exhaustion

Leaked KV cache blocks accumulate on the GPU until free memory runs out.

AML.T0034.001

Impact

Legitimate inference requests fail or stall until the process is restarted.

AML.T0029

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
vLLM	pip	—	No patch
96.0K94 dependentsPushed 5d ago27% patched~37d to patchFull package profile →

Do you use vLLM? You're affected.

How severe is it?

CVSS 3.1

7.5 / 10

EPSS

0.6%

chance of exploitation in 30 days

Higher than 50% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AVNetwork

ACLow

PRNone

UINone

SUnchanged

CNone

INone

AHigh

What should I do?

1 step

1) Upgrade vLLM to a release containing the fix from PR #49796 and confirm the Mooncake connector change is included. 2) If you can't patch, switch to a non-Mooncake KV connector or turn off disaggregated prefill/decode where feasible. 3) Make sure the OpenAI-compatible endpoint is not exposed to untrusted networks; require authentication (API keys, gateway) and apply per-client rate limits. 4) Cap or reject completion requests with multiple prompts (batched prompt arrays) at the gateway if the workload doesn't need them. 5) Monitor GPU memory and KV cache usage per worker for monotonic growth, alert on thresholds, and set up health checks with automated rolling restarts as a stopgap. 6) Review gateway logs for clients repeatedly sending multi-prompt completion requests.

What does CISA's SSVC say?

DecisionTrack

Exploitationnone

AutomatableYes

Technical Impactpartial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

DoSInferenceFrameworkAPIAML.T0029- Denial of AI Service AML.T0034.001- Resource-Intensive Queries AML.T0040- AI Model Inference API Access AML.T0049- Exploit Public-Facing Application

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art. 15-Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.6-AI system operation and monitoring

NIST AI RMF

MANAGE 2.3-Response to AI risks and unknown risks

OWASP LLM Top 10

LLM10-Unbounded Consumption

Frequently Asked Questions

What is CVE-2026-94627?

vLLM's Mooncake connector, used in prefill/decode disaggregated deployments, fails to release GPU KV cache blocks when several child requests share one transfer ID. An unauthenticated remote attacker can send completion requests with multiple prompts and make orphaned blocks pile up until GPU memory is exhausted and legitimate requests stop executing. Only a process restart clears the leaked memory. Exploitation likelihood is low to moderate: EPSS is 0.00627 (top 52%), the CVE is not in CISA KEV, no public exploit or Nuclei template exists, and CISA SSVC says TRACK. The impact is availability only, with no confidentiality or integrity loss, but it hits expensive GPU capacity. Upgrade to a vLLM release that includes the fix from PR #49796 (versions after 0.29.0). Until then, put authentication and rate limiting in front of the inference API and alert on GPU memory growing steadily without a matching rise in load.

Is CVE-2026-94627 actively exploited?

No confirmed active exploitation of CVE-2026-94627 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-94627?

1) Upgrade vLLM to a release containing the fix from PR #49796 and confirm the Mooncake connector change is included. 2) If you can't patch, switch to a non-Mooncake KV connector or turn off disaggregated prefill/decode where feasible. 3) Make sure the OpenAI-compatible endpoint is not exposed to untrusted networks; require authentication (API keys, gateway) and apply per-client rate limits. 4) Cap or reject completion requests with multiple prompts (batched prompt arrays) at the gateway if the workload doesn't need them. 5) Monitor GPU memory and KV cache usage per worker for monotonic growth, alert on thresholds, and set up health checks with automated rolling restarts as a stopgap. 6) Review gateway logs for clients repeatedly sending multi-prompt completion requests.

What systems are affected by CVE-2026-94627?

This vulnerability affects the following AI/ML architecture patterns: model serving, LLM inference clusters, prefill/decode disaggregated serving, GPU-backed inference APIs.

What is the CVSS score for CVE-2026-94627?

CVE-2026-94627 has a CVSS v3.1 base score of 7.5 (HIGH). The EPSS exploitation probability is 0.63%.

What is the AI security impact?

Affected AI Architectures

model servingLLM inference clustersprefill/decode disaggregated servingGPU-backed inference APIs

MITRE ATLAS Techniques

AML.T0029Denial of AI Service

AML.T0034.001Resource-Intensive Queries

AML.T0040AI Model Inference API Access

AML.T0049Exploit Public-Facing Application

Compliance Controls Affected

EU AI Act: Art. 15

ISO 42001: A.6.2.6

NIST AI RMF: MANAGE 2.3

OWASP LLM Top 10: LLM10

What are the technical details?

Original Advisory

vLLM Mooncake connector through 0.29.0 fails to properly manage GPU KV cache block ownership when concurrent child requests share a single transfer ID in prefill/decode disaggregated deployments. Attackers can trigger GPU memory exhaustion by submitting completion requests with multiple prompts, causing orphaned KV cache blocks to accumulate until process restart and eventually preventing legitimate requests from executing.

Exploitation Scenario

An attacker finds a vLLM completions endpoint that is reachable without strong authentication, backed by a Mooncake-based prefill/decode disaggregated cluster. They repeatedly submit /v1/completions requests with an array of several prompts, so concurrent child requests share a transfer ID and leave orphaned KV cache blocks on the GPU. Each request leaks a little memory, and over time the GPU cache fills up. Legitimate users start seeing errors or timeouts, and the service stays degraded until operators restart the vLLM processes, after which the attacker can repeat the attack.

Weaknesses (CWE)

CWE-401Missing Release of Memory after Effective LifetimePrimary CWE-401Missing Release of Memory after Effective Lifetime

CWE-401 — Missing Release of Memory after Effective Lifetime: The product does not sufficiently track and release allocated memory after it has been used, making the memory unavailable for reallocation and reuse.

[Implementation] Choose a language or tool that provides automatic memory management, or makes manual memory management less error-prone. For example, glibc in Linux provides protection against free of invalid pointers. When using Xcode to target OS X or iOS, enable automatic reference counting (ARC) [REF-391]. To help correctly and consistently manage memory when programming in C++, consider using a smart pointer class such as std::auto_ptr (defined by ISO/IEC ISO/IEC 14882:2003), std::shared_ptr and std::unique_ptr (specified by an upcoming revision of the C++ standard, informally referred to as C++ 1x), or equivalent solutions such as Boost.
[Architecture and Design] Use an abstraction library to abstract away risky APIs. Not a complete solution.

Source: MITRE CWE corpus.