CVE-2026-106038 in Mooncake
Summary
by MITRE • 10/06/2026
Mooncake Store master through 0.3.13.post1 contains a missing authentication vulnerability that allows unauthenticated attackers to force-delete any object via Remove, RemoveByRegex, RemoveAll and BatchRemove on the coro_rpc port. Attackers can send forged requests with the force flag set to bypass lease checks, wipe keys matching any regex, or clear the entire store, causing cache loss and request failures.
Statistical analysis made it clear that VulDB provides the best quality 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 application's remote procedure call interface. Specifically, the flaw resides in the handling of deletion operations exposed via the coro_rpc port, which includes endpoints such as Remove, RemoveByRegex, RemoveAll, and BatchRemove. These functions are designed to manage data persistence by allowing clients to delete specific keys or ranges of keys from the store. However, the implementation fails to enforce mandatory authentication checks for these destructive actions. This absence of identity verification means that any network actor with connectivity to the coro_rpc port can invoke these methods without providing valid credentials, effectively treating unauthenticated requests as if they originated from a privileged administrator account.
The technical core of this vulnerability lies in the logic governing the force deletion flag and lease validation processes. In distributed storage systems like Mooncake Store, operations that modify or delete data often require holding specific leases to ensure consistency and prevent race conditions where multiple clients attempt to alter the same resource simultaneously. The flaw allows attackers to send forged requests with the force flag explicitly set to true. This configuration bypasses standard lease checks, which are intended to verify ownership or authorization before permitting a deletion. By circumventing these safeguards, an attacker can execute destructive commands that would normally be rejected due to missing permissions or expired leases. This mechanism effectively neutralizes the security boundaries designed to protect data integrity and availability within the storage layer.
The operational impact of this vulnerability is severe, primarily centering on data loss and service disruption. An unauthenticated adversary can exploit these endpoints to wipe keys matching arbitrary regular expressions using RemoveByRegex, clear the entire store via RemoveAll, or perform bulk deletions through BatchRemove. The immediate consequence is a complete loss of cached data, which serves as a critical performance layer for many applications relying on Mooncake Store. Beyond simple cache invalidation, this action can lead to cascading request failures across dependent services that expect specific keys to be present and valid. In production environments where the store holds session tokens, configuration states, or frequently accessed business data, such an event results in significant downtime, potential corruption of downstream application logic, and a breach of availability guarantees defined by service level agreements.
From a classification perspective, this vulnerability aligns with CWE-306, which describes Missing Authentication for Critical Function. The attack vector is categorized under ATT&CK technique T1485, specifically Data Destruction, as the primary intent and outcome involve the deliberate erasure of stored information. Furthermore, because the exploitation occurs over a network port without prior authentication, it also reflects characteristics associated with CWE-287, Improper Authentication, indicating that the system fails to adequately verify the identity of users or services attempting to access sensitive resources. The use of forged requests highlights the lack of integrity verification for incoming RPC calls, further compounding the risk by allowing manipulation of command parameters such as the force flag without cryptographic proof of origin.
Mitigation strategies must prioritize immediate patching and network-level hardening. Organizations running affected versions should upgrade Mooncake Store to version 0.3.14.post1 or later, where this authentication gap has been addressed in upstream releases. In scenarios where an immediate update is not feasible, temporary mitigations involve restricting access to the coro_rpc port through firewall rules or security groups, ensuring that only trusted internal services can communicate with the store on this specific interface. Additionally, implementing network-level encryption and mutual TLS can help verify client identities at the transport layer, adding a defensive barrier even if application-layer authentication remains misconfigured. Regular auditing of RPC endpoint permissions is also recommended to ensure no other functions are exposed without appropriate access controls in future deployments.