Description

Mooncake transfer engine through 0.3.13.post1 contains a denial of service vulnerability that allows unauthenticated remote attackers to block the handshake daemon by never reading replies. Attackers can send a Metadata request to the handshake RPC port and stall SocketHandShakePlugin's single listener thread in writeFully(), breaking all subsequent handshakes, metadata fetches, notify and probe requests.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.9",
  "pubDate": "2026-10-01T23:16:46.817Z",
  "pubdate": "2026-10-01T23:16:46.817Z",
  "executiveSummary": "Mooncake transfer engine versions through 0.3.13.post1 are susceptible to a Denial of Service (DoS) vulnerability originating from an insecure RPC handling mechanism.\nThe vulnerability allows an unauthenticated remote attacker to cause a complete service disruption of the handshake daemon.\nBy manipulating the interaction with the handshake RPC port, an attacker can stall a critical internal thread, effectively halting all subsequent handshake, metadata, notification, and probe requests.\nThis vulnerability poses a significant risk to system availability, as the single-threaded nature of the affected listener prevents recovery without manual intervention or service restarts.\nExploitation is trivial and does not require authentication or elevated privileges, allowing any network-adjacent or remote attacker with access to the RPC port to disrupt the transfer engine's functionality entirely.",
  "technicalDetails": "The vulnerability resides within the SocketHandShakePlugin component of the Mooncake transfer engine. The root cause is the reliance on a single listener thread to manage incoming requests combined with improper handling of blocked write operations in the writeFully() function.\nThe attack flow begins when an attacker transmits a specially crafted Metadata request to the handshake RPC port. Because the system is designed to handle this communication synchronously, the SocketHandShakePlugin attempts to send a reply back to the requesting entity.\nThe vulnerability is triggered when the attacker purposefully fails to consume or read the data sent by the daemon. By neglecting to read the response, the TCP receive buffer on the attacker's side remains full, which causes the socket's write operation on the server side to block.\nSince the SocketHandShakePlugin operates on a single listener thread, the execution flow enters a permanent stall while trapped in the writeFully() method. This thread is effectively deadlocked waiting for the socket to clear, rendering the entire daemon incapable of processing any further network traffic.\nOnce the listener thread is blocked, the service becomes unresponsive. All subsequent operations that rely on this handshake daemon—including standard handshakes, metadata fetches, notify signals, and probe requests—fail, leading to a complete denial of service for the transfer engine. Because the thread is occupied by the stalled write operation, it cannot service new requests or perform health checks, necessitating a restart of the affected daemon to restore normal operation.\nThe lack of timeouts or non-blocking I/O primitives for the writeFully() operation allows an unauthenticated attacker to persistently exhaust the service's availability with minimal effort or resource consumption. This represents a critical architectural flaw in how the system manages synchronous RPC responses over network sockets."
}