CVE-2026-106037 in Mooncake
Summary
by MITRE • 10/06/2026
Mooncake through 0.3.13.post1 contains a missing authentication vulnerability in the Store REST service, which binds to 0.0.0.0 without authentication on any route. Unauthenticated attackers can call routes such as /api/get, /api/put, /api/remove_all and /api/mount to read cached KV data with user prompts, inject or delete objects, and mount attacker-described segments.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/06/2026
The Mooncake project, specifically versions up through 0.3.13.post1, suffers from a critical missing authentication vulnerability within its Store REST service architecture. This flaw stems from the service binding to all available network interfaces on address 0.0.0.0 without implementing any form of access control or authentication mechanisms for incoming requests. By exposing the API endpoints directly to unauthenticated traffic across the entire network, the application fails to enforce identity verification before processing sensitive operations. This configuration error effectively turns a potentially secure internal service into an open portal accessible by any entity capable of reaching the host machine over the network, whether that be local processes or remote attackers depending on the deployment environment and firewall rules.
The technical nature of this vulnerability aligns with CWE-287, which describes Improper Authentication, as well as CWE-306, Missing Authentication for Critical Function. The REST service exposes several high-risk endpoints including /api/get, /api/put, /api/remove_all, and /api/mount without requiring valid credentials or tokens. In a typical secure implementation, these operations would require explicit authorization checks to ensure that the requesting user has permission to perform data retrieval, modification, deletion, or system configuration changes. The absence of such checks allows any unauthenticated actor to interact with the backend storage logic directly through standard HTTP requests, bypassing all intended security boundaries designed to protect the integrity and confidentiality of the stored key-value pairs and associated metadata.
The operational impact of this vulnerability is severe due to the breadth of actions available to an attacker via these exposed routes. Through the /api/get endpoint, attackers can read cached key-value data that may contain sensitive user prompts or proprietary information, leading to a significant compromise of confidentiality. The /api/put and /api/remove_all endpoints allow for arbitrary injection of new objects into the store and the complete deletion of existing data respectively, which directly impacts data integrity and availability. Furthermore, the /api/mount endpoint enables attackers to mount attacker-described segments, potentially allowing them to manipulate underlying storage structures or gain further access to system resources depending on how these mounts are processed by the host operating system. This combination of capabilities effectively grants an unauthenticated user full read-write-delete control over the application's data store and potential influence over its operational state.
From a threat modeling perspective using the MITRE ATT&CK framework, this vulnerability facilitates multiple attack techniques including Data Injection (T1564), Data Manipulation (T1074), and potentially Remote File Copy or Execution depending on the specifics of the mount functionality (T1105). The lack of authentication serves as a foundational weakness that enables these subsequent malicious activities. Attackers can exploit this to exfiltrate sensitive data, corrupt application state by deleting critical records, or inject malformed objects that could lead to further vulnerabilities such as injection attacks if those values are later processed without sanitization elsewhere in the system stack.
To mitigate this vulnerability, immediate remediation is required for all deployments running Mooncake versions up through 0.3.13.post1. The primary fix involves implementing robust authentication and authorization mechanisms on the Store REST service endpoints to ensure that only authorized users or services can access these APIs. This should include using industry-standard protocols such as OAuth2, JWT tokens, or API keys with strict validation logic. Additionally, developers should enforce principle of least privilege by binding the service to localhost (127.0.0.1) if remote network access is not strictly required, thereby limiting exposure to only local processes that are already trusted within the system boundary. If external access is necessary, a reverse proxy with authentication capabilities or an API gateway should be placed in front of the service to handle identity verification before requests reach the Mooncake application layer. Regular security audits and penetration testing should also be conducted to verify that no other endpoints remain exposed without proper protection measures.