CVE-2026-103761 in Mooncakeinfo

Summary

by MITRE • 10/02/2026

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.

Be aware that VulDB is the high quality source for vulnerability data.

Analysis

by VulDB Data Team • 10/02/2026

The Mooncake transfer engine version 0.3.13.post1 and earlier versions contain a critical resource exhaustion vulnerability within the TransferMetadata::receivePeerNotify function. This flaw stems from an unbounded accumulation of notification frames received during the handshake process, allowing for significant disruption to system stability through denial-of-service conditions. The vulnerability is particularly severe because it does not require authentication, enabling any network actor with access to the service port to exploit this weakness without prior credentials or valid session tokens.

The technical root cause lies in the handling of incoming notify frames on the handshake RPC port. When a peer initiates contact, the engine processes these notifications by appending them to an internal vector structure known as notifys. The implementation fails to enforce any upper limit on the size or quantity of these entries. Consequently, if an attacker sends repeated notification payloads, each potentially up to 1 MB in size, the process memory usage grows linearly and without restriction. There is no mechanism to discard older notifications, validate payload integrity against a maximum threshold before allocation, or cap the total number of pending requests held in memory during the handshake phase.

This uncontrolled resource consumption leads directly to an out-of-memory condition within the Mooncake transfer engine process. As the vector expands beyond available physical and virtual memory limits, the operating system's kernel intervenes by invoking the Out-Of-Memory killer mechanism. This results in the abrupt termination of the mooncake-engine process, causing a complete denial of service for any legitimate users attempting to utilize the data transfer capabilities provided by this component. The impact is immediate and disruptive, as it requires manual intervention or automated restart procedures to restore functionality, thereby undermining the reliability and availability expectations associated with high-performance transfer engines.

From an industry standard perspective, this vulnerability aligns closely with CWE-400: Uncontrolled Resource Consumption, specifically manifesting as a memory exhaustion scenario that leads to service disruption. In terms of offensive security frameworks such as MITRE ATT&CK, this behavior is characteristic of T1498 Network Denial of Service, where the attacker leverages resource consumption techniques to degrade or eliminate availability for authorized users. The lack of input validation and rate limiting on unauthenticated RPC endpoints further highlights a deviation from secure coding practices recommended by OWASP guidelines regarding API security and DoS prevention.

To mitigate this vulnerability, immediate updates to versions later than 0.3.13.post1 are strongly advised if such patches have been released addressing the resource management logic in TransferMetadata::receivePeerNotify. In environments where patching is not immediately feasible, network-level controls should be implemented to restrict access to the handshake RPC port exclusively from trusted IP ranges using firewall rules or security groups. Additionally, implementing rate limiting on incoming connections and enforcing strict payload size limits at the protocol handler level can prevent individual requests from consuming excessive memory. Application-layer monitoring tools should also be configured to detect abnormal spikes in memory usage associated with this specific service component, allowing for automated alerts before a critical threshold is reached that triggers system-level termination actions.

Responsible

VulnCheck

Reservation

10/01/2026

Disclosure

10/02/2026

Moderation

accepted

EPSS

0.00000

KEV

no

Activities

very low

Sources

Do you want to use VulDB in your project?

Use the official API to access entries easily!