CVE-2026-106040 in Mooncake
Summary
by MITRE • 10/06/2026
Mooncake Store master through 0.3.13.post1 contains a missing authorization vulnerability that allows unauthenticated attackers to erase any object's disk replica via EvictDiskReplica and BatchEvictDiskReplica. Attackers reaching the coro_rpc master port can evict DISK replicas across all tenants, deleting objects whose only remaining replica is on disk.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/06/2026
The vulnerability identified in Mooncake Store versions through 0.3.13.post1 represents a critical failure in access control mechanisms within the distributed storage system's remote procedure call interface. Specifically, the flaw resides in the handling of the EvictDiskReplica and BatchEvictDiskReplica RPC methods exposed via the coro_rpc master port. These endpoints are designed to manage data redundancy by removing specific replicas from nodes when necessary for maintenance or rebalancing operations. However, due to a missing authorization check, these sensitive administrative functions can be invoked by any client that has network connectivity to the master node's RPC interface, regardless of whether the caller possesses valid credentials or belongs to an authorized tenant group. This lack of authentication and authorization enforcement effectively turns critical data management tools into weapons for malicious actors who have gained basic network access to the service port.
From a technical perspective, this is a classic example of broken object level authorization where the server fails to verify that the requesting user has permission to perform actions on specific resources or within their designated tenant scope. In a multi-tenant architecture like Mooncake Store, isolation between tenants is paramount for data security and privacy. By allowing unauthenticated users to trigger replica eviction across all tenants, the system violates fundamental principles of logical separation. The attacker does not need to exploit complex buffer overflows or injection flaws; they simply need to send properly formatted RPC requests to the master port. Because the server processes these commands without validating the caller's identity or permissions, it proceeds with the deletion instructions as if they originated from an authorized administrator.
The operational impact of this vulnerability is severe and potentially catastrophic for data integrity and availability. When a disk replica is evicted, the system removes that copy of the object from storage nodes to free up space or resolve consistency issues. If an attacker targets objects whose only remaining replica resides on disk, they can effectively cause permanent data loss. Unlike cloud-based replicas which might have other copies in different regions, disk-local replicas are often critical for immediate access and durability guarantees. By systematically evicting these last-resort copies, an unauthenticated attacker can render specific datasets irretrievable without leaving obvious traces of a brute-force attack or system crash. This constitutes a direct threat to the confidentiality, integrity, and availability triad, with data destruction being the primary consequence rather than unauthorized access to sensitive information.
This vulnerability aligns closely with CWE-284 Improper Access Control, specifically highlighting failures in verifying user privileges before executing state-changing operations. Furthermore, it maps to MITRE ATT&CK technique T1070 Indicator Removal on Host or more broadly T1485 Data Destruction, as the attacker's intent and outcome involve the deliberate deletion of data artifacts. The attack vector is classified under Network-Based attacks because exploitation requires only network reachability to the specific RPC port, making it accessible to any entity within the same network segment or with routed access to that service.
Mitigation strategies must prioritize immediate remediation through software updates followed by robust architectural hardening. Users running Mooncake Store versions prior to 0.3.13.post1 should upgrade to a patched version where proper authentication and authorization checks have been implemented for all administrative RPC endpoints. In the interim, or as an additional layer of defense, network segmentation is essential. The coro_rpc master port should not be exposed directly to untrusted networks; instead, it must be restricted via firewall rules to only allow connections from known management nodes or authorized service accounts. Implementing mutual TLS authentication for internal services can further ensure that even if the RPC interface is accessible, only verified clients with valid certificates can invoke sensitive operations like replica eviction. Regular audits of access control lists and continuous monitoring of RPC call patterns for anomalies such as high-frequency evictions from unknown sources are also recommended to detect potential exploitation attempts early.