Description

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 Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-10-01T23:16:46.987Z",
  "pubdate": "2026-10-01T23:16:46.987Z",
  "executiveSummary": "Mooncake transfer engine versions through 0.3.13.post1 are susceptible to a critical memory exhaustion vulnerability residing within the TransferMetadata::receivePeerNotify function.\nThis flaw enables unauthenticated, remote attackers to trigger an uncontrolled expansion of process memory, ultimately leading to a denial-of-service condition via the out-of-memory (OOM) killer.\nThe vulnerability stems from an uncapped vector data structure that fails to enforce bounds on incoming notification frames processed via the handshake RPC port.\nBy repeatedly transmitting malicious notify frames, an attacker can incrementally consume system resources until the host process is terminated by the operating system.\nThe impact is significant, as it allows for trivial service disruption without requiring prior authentication or elevated privileges, posing a severe risk to service availability in exposed infrastructure.",
  "technicalDetails": "The vulnerability is localized to the TransferMetadata::receivePeerNotify function within the Mooncake transfer engine, which is responsible for handling incoming peer notification frames during the handshake phase of RPC communication.\nThe root cause is the implementation of a 'notifys' vector which lacks size validation or rate-limiting mechanisms for ingested data. When the engine receives a notify frame, it appends the frame directly into the internal vector structure without verifying the current resource utilization or imposing a maximum depth or quantity of stored frames.\nExploitation is achieved through the handshake RPC port, which is exposed to network traffic. An attacker can craft and transmit a series of notify frames, each up to 1 MB in size, targeting the specific endpoint handling the notification logic.\nBecause the 'notifys' vector is unbounded, each incoming request adds to the total memory footprint of the Mooncake process. There is no reclamation or pruning logic active during this phase, meaning the process memory footprint grows linearly with each malicious frame sent.\nThe attack flow follows a repetitive pattern: 1) The attacker initiates a connection to the handshake RPC port. 2) The attacker submits a malicious notification frame. 3) The TransferMetadata::receivePeerNotify function parses the frame and pushes it into the 'notifys' vector. 4) The process allocates additional heap memory to accommodate the vector's expansion. 5) By looping these steps, the attacker forces the process to consume available system RAM.\nOnce the allocated memory exceeds available system or cgroup thresholds, the Linux OOM killer identifies the Mooncake process as the primary candidate for termination to preserve system stability, resulting in a successful denial-of-service attack.\nThe vulnerability is particularly dangerous due to its unauthenticated nature, meaning any entity capable of reaching the handshake RPC port can execute the exploit. The lack of validation logic within the affected function effectively turns the handshake mechanism into an amplification vector for memory exhaustion.\nAffected versions include all releases through 0.3.13.post1. No specific privilege requirements are necessary for exploitation, as the vulnerability is triggered during the early handshake phase, preceding authentication protocols."
}