Skip to main content

Mooncake Transfer Engine EUVDEUVD-2026-91135

| CVE-2026-103761 HIGH
Allocation of Resources Without Limits or Throttling (CWE-770)
2026-10-01 VulnCheck GHSA-62mv-x7jm-w9f4
8.7
CVSS 4.0 · Vendor: VulnCheck
View

Attack ChainAIDerived

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

  1. Access
    Reach handshake RPC port
  2. Delivery
    Send 1 MB notify frames
  3. Exploit
    Append to uncapped notifys vector
  4. Execution
    Repeat to exhaust memory
  5. Impact
    OOM killer terminates engine

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V2 - Validation and Business Logic Resource allocation limits
MITRE ATT&CK

1 technique across 1 tactic: Impact

The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up.

Exploitation Conditions

Exploitation requires only network access to the Mooncake transfer engine's handshake RPC port; the attacker sends notify frames (up to 1 MB each) that are appended to the unbounded notifys vector in TransferMetadata::receivePeerNotify. No authentication is required (PR:N) and no user interaction or special configuration is needed - any default deployment that exposes the handshake RPC port is vulnerable. The practical limiting factor is network exposure of that RPC port: deployments where the port is bound to localhost or restricted to a trusted cluster network by firewalling/segmentation are not reachable by external attackers, which is the primary realistic mitigation until an upstream fix (bounding the notifys vector) is applied.

Impact

All available signals converge on a genuine but bounded availability risk. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) confirms a trivially reachable, remote, unauthenticated attack requiring no user interaction or special conditions, and the impact profile is purely availability (VC:N/VI:N/VA:H) consistent with CWE-770 uncontrolled resource consumption - there is no confidentiality or integrity exposure. The score of 8.7 (High) is driven entirely by the ease of triggering a reliable denial of service, not by any code-execution or data-compromise potential, so this should be triaged as a service-availability issue rather than a system-compromise one. No EPSS score, CISA KEV listing, or public POC was supplied in the input, so there is no evidence of active exploitation or weaponization; the vulnerability is realistically exploitable (the mechanism is simple and well-documented by VulnCheck with a direct source-line reference) but not confirmed as being exploited in the wild. The main mitigating factor on real-world priority is deployment footprint: Mooncake is specialized LLM-serving infrastructure, so this is a real priority specifically for organizations running Mooncake-based inference, and comparatively low-urgency for everyone else.

Exploit ScenarioDerived

An attacker with network reachability to a Mooncake transfer engine's handshake RPC port repeatedly sends crafted notify frames of up to 1 MB each, with no authentication required. Because the notifys vector in TransferMetadata::receivePeerNotify is uncapped, each frame permanently grows process memory until the Linux OOM killer terminates the engine, taking down the LLM inference service. No public exploit code was identified at time of analysis, but the attack is mechanically simple to reproduce from the public issue and source reference.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
No patch listed yet 0.4% exploitation probability (EPSS)

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

Alert me

AnalysisAIv1 – Oct 01, 2026

Unauthenticated memory exhaustion in the Mooncake transfer engine (all versions through 0.3.13.post1) allows any network client that can reach the handshake RPC port to grow process memory without limit and force the out-of-memory killer to terminate the engine. Attackers simply replay notify frames of up to 1 MB each into TransferMetadata::receivePeerNotify, which appends every notification to an uncapped 'notifys' vector with no size, count, or peer-identity check; the CVSS 4.0 base score of 8.7 reflects uniformly high availability impact (VA:H) with no confidentiality or integrity loss. No authentication, user interaction, or special configuration is required (PR:N, UI:N), so any default deployment that exposes the handshake RPC port to an untrusted network is reachable; no public exploit code was identified at time of analysis and the flaw is not listed in CISA KEV, so this remains a bounded denial-of-service risk whose practical exposure depends almost entirely on whether that RPC port is firewalled or bound to localhost.

RemediationAI

No vendor-released patch was identified at time of analysis; the upstream issue (https://github.com/kvcache-ai/Mooncake/issues/4445) and the referenced VulnCheck advisory (https://www.vulncheck.com/advisories/mooncake-transfer-engine-through-0.3.13-post1-memory-exhaustion-via-unbounded-notify-queue) should be monitored for a fixed release, and upgrading past 0.3.13.post1 once a version that bounds or prunes the 'notifys' vector is published is the only complete fix. Until then, the highest-value control is closing the exposure surface: bind the handshake RPC port to localhost or a private interface and firewall it so that only known peer nodes in the cluster can connect, which is exactly the deployment posture that renders the attack unreachable - accepting that this breaks legitimate cross-network transfer topologies that rely on remote peers reaching the port. Where the port must stay reachable, layer compensating controls with explicit trade-offs: enforce per-source connection and rate limits at a fronting proxy or the host firewall so a single peer cannot flood notify frames (adds latency and may throttle legitimate large-scale handshakes), place the engine process in a cgroup/container memory limit so an OOM is contained to that process rather than the host (the engine still dies, it just does not take down co-located workloads), and add supervision that restarts the engine and alerts on rapid RSS growth or repeated OOM kills (restarts cause transient cache loss and re-handshake storms). Because exploitation requires only network access with no credentials or user interaction, monitoring outbound/inbound traffic to the handshake port for a high volume of small peer frames from unexpected sources is a useful detection signal; note that no patch version number should be assumed until the vendor publishes one, and the CPE entry cpe:2.3:a:kvcache-ai:mooncake:*:*:*:*:*:*:*:* provides no version boundary to scope remediation by itself.

Affected VersionsENISA

mooncake 0 ≤0.3.13.post1

Affected Packages

euvd mooncake no fix

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

Mooncake is a KVCache-centric transfer engine (kvcache-ai/Mooncake) used to move KV-cache and tensor data between inference workers; its transfer engine coordinates peers over a handshake RPC channel and keeps per-peer metadata in TransferMetadata. The vulnerable routine, TransferMetadata::receivePeerNotify (referenced at transfer_metadata.cpp lines 285-296 in commit 71973589), accepts notify frames from the RPC layer and pushes them into a std::vector<...> notifys that is never bounded, trimmed, or deduplicated. This is a textbook CWE-770 (Allocation of Resources Without Limits or Throttling): each inbound frame can be as large as 1 MB, and because there is no cap on the number of retained entries and no verification that the sender is an authenticated or previously known peer, memory consumption scales linearly with attacker-supplied traffic until the kernel OOM killer kills the engine process. The supplied CPE cpe:2.3:a:kvcache-ai:mooncake:*:*:*:*:*:*:*:* carries no version constraint, consistent with the description that the issue affects the engine through 0.3.13.post1 (i.e., all released versions at the time of disclosure). The CVSS 4.0 vector provided (AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N) and the independent assessment (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) agree that this is a pure availability defect reachable over the network with no privileges and no attack complexity.

Know when Mooncake 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 8.7 HIGH
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
vuln.today AI 7.5 HIGH

Remote unauthenticated frames to an exposed RPC port with no user interaction (AV:N/AC:L/PR:N/UI:N); impact is memory-exhaustion DoS only, so A:H with C:N/I:N.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

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
High
Subsequent system: Confidentiality
None
Subsequent system: Integrity
None
Subsequent system: Availability
None

DescriptionCVE.org

Mooncake transfer engine through 0.3.13.post1 contains a memory exhaustion vulnerability in TransferMetadata::receivePeerNotify that allows unauthenticated attackers to grow process memory without limit. Attackers can repeatedly send notify frames up to 1 MB to the handshake RPC port, filling the uncapped notifys vector until the out-of-memory killer terminates the engine.

Executive ViewAI

Why It Matters

The Mooncake transfer engine, in all versions through 0.3.13.post1, is affected by an unauthenticated memory-exhaustion flaw that can crash the engine and disrupt data-transfer operations. Because the handshake RPC port can be reached by any network client if exposed, leadership should treat this as a high-availability risk for externally accessible deployments. No public exploit identified at time of analysis, but no vendor-released patch is available, so containment depends on limiting network exposure.

Business Impact: High
Compensating Controls

Restrict network access to the handshake RPC port to trusted peers via firewall, security group, or ACL; apply network segmentation; monitor Mooncake process memory and configure automated restart; where supported, enforce connection-rate or frame-size limits at the network layer; track vendor advisory for a fixed version.

Threat Intelligence Overview

EPSS Score
0.4%
Top 72% exploitable
Prevalence
Low
specialized open-source LLM KV-cache serving infrastructure, niche deployment
Social Media
2
Sightings
Data Quality
6 sources
Confidence: High
EUVD NVD CVE.org EPSS Vulnrichment CIRCL 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 HIGH
CISA KEV No
Public POC No
EPSS 0.4%
Patch available No
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.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
Scheduled
Exploitation
Poc
System Exposure· derived
Open
Automatable
Yes
Human Impact
High
Technical Impact
Partial

Priority Score

44
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +44
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.

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