CVE-2026-103760 in Mooncake
Summary
by MITRE • 10/02/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/02/2026
The Mooncake transfer engine version 0.3.13.post1 contains a critical denial of service vulnerability that stems from improper handling of network connections within its handshake daemon architecture. This flaw allows unauthenticated remote attackers to disrupt the availability of the system by exploiting the synchronous nature of the connection management logic. Specifically, an attacker can send a Metadata request to the handshake RPC port and then deliberately fail to read any replies returned by the server. This action causes the SocketHandShakePlugin's single listener thread to become permanently blocked while waiting in the writeFully() method for space in the output buffer or acknowledgment from the client. Because this plugin relies on a single-threaded model for handling handshake operations, one stalled connection effectively monopolizes the resource, preventing any other concurrent requests from being processed.
The operational impact of this vulnerability is severe and comprehensive within the scope of the Mooncake transfer engine's communication layer. By stalling the listener thread in writeFully(), an attacker can break all subsequent handshakes, metadata fetches, notify operations, and probe requests initiated by legitimate clients or services. This results in a complete denial of service for any component relying on this handshake mechanism to establish secure connections or retrieve configuration data. The system becomes unresponsive to new connection attempts, effectively halting the transfer engine's ability to manage distributed tasks or synchronize state across nodes. Since the vulnerability requires no authentication, it can be exploited by any network-accessible entity with minimal effort, making it a high-risk threat for environments where Mooncake is deployed without strict network segmentation or access controls.
From a classification perspective, this issue aligns with CWE-400: Uncontrolled Resource Consumption, as the application fails to limit the resources consumed by a single connection attempt. The attack vector involves sending malicious input that causes the system to enter an infinite wait state, which is also characteristic of CWE-613: Insufficient Session Expiration if session timeouts are not properly configured or enforced at the protocol level. In terms of adversarial tactics, this behavior corresponds to ATT&CK technique T1499: Endpoint Denial of Service, specifically under sub-techniques involving resource exhaustion through application layer flooding or blocking. The exploitation relies on manipulating the state machine of the handshake process rather than crashing the service outright, which makes it difficult to detect via simple crash-based monitoring tools.
Mitigation strategies should focus on implementing robust timeout mechanisms and connection limits within the Mooncake transfer engine's networking stack. Administrators should configure strict idle timeouts for both read and write operations in the SocketHandShakePlugin to ensure that connections stuck in a blocked state are forcibly terminated after a defined period. Additionally, enforcing rate limiting on incoming handshake requests can help mitigate the impact of volumetric attacks targeting this specific endpoint. Upgrading to patched versions of Mooncake where these concurrency issues have been resolved is the most effective long-term solution. Until patches are applied, deploying network-level access control lists to restrict who can connect to the handshake RPC port provides a necessary layer of defense against unauthenticated exploitation attempts.