Summary
Mooncake's Store REST service may bind to all network interfaces without requiring authentication on its routes. An unauthenticated attacker who can reach the service could read cached key-value data, insert or delete stored objects, or mount attacker-defined segments.
Mooncake's Store REST service may bind to all network interfaces without requiring authentication on its routes. An unauthenticated attacker who can reach the service could read cached key-value data, insert or delete stored objects, or mount attacker-defined segments.
Affected context
The vulnerability occurs in Mooncake deployments using the Store REST service through version 0.3.13.post1, where the service listens on 0.0.0.0 without authentication controls applied to its routes. Risk depends on network exposure and whether the service is reachable by untrusted clients. Relevant operations include cached-data retrieval, object insertion, object removal, and segment mounting.
The vulnerability occurs in Mooncake deployments using the Store REST service through version 0.3.13.post1, where the service listens on 0.0.0.0 without authentication controls applied to its routes. Risk depends on network exposure and whether the service is reachable by untrusted clients. Relevant operations include cached-data retrieval, object insertion, object removal, and segment mounting.
Exploit preconditions
- Attack surface: Mooncake Store REST service and its HTTP routes - Required access: Network connectivity to the exposed service; no valid
credentials are required
- Trigger point: Requests to Store API operations such as get, put,
remove_all, or mount
- Why exploitation is possible: The service accepts requests without
authenticating callers, allowing unauthorised clients to invoke
state-changing and data-access operations
- Attack surface: Mooncake Store REST service and its HTTP routes - Required access: Network connectivity to the exposed service; no valid
credentials are required
- Trigger point: Requests to Store API operations such as get, put,
remove_all, or mount
- Why exploitation is possible: The service accepts requests without
authenticating callers, allowing unauthorised clients to invoke
state-changing and data-access operations
Why this happens
The underlying flaw is a missing authentication check on a network-facing REST service. Binding the service to all interfaces without requiring caller identity allows route handlers to process requests based solely on network reachability. This maps to CWE-306, which covers missing authentication for a critical function, because sensitive data and administrative storage actions are available without verifying the requester.
The underlying flaw is a missing authentication check on a network-facing REST service. Binding the service to all interfaces without requiring caller identity allows route handlers to process requests based solely on network reachability. This maps to CWE-306, which covers missing authentication for a critical function, because sensitive data and administrative storage actions are available without verifying the requester.
Potential impact
- Unauthenticated users may read cached key-value data and associated prompts.
- Attackers could inject objects or alter data consumed by applications.
- Attackers could delete stored objects or disrupt service availability.
- Malicious clients may mount attacker-described segments.
- Compromised cached data could contribute to downstream data poisoning.
- Unauthenticated users may read cached key-value data and associated prompts.
- Attackers could inject objects or alter data consumed by applications.
- Attackers could delete stored objects or disrupt service availability.
- Malicious clients may mount attacker-described segments.
- Compromised cached data could contribute to downstream data poisoning.
General mitigation guidance
Mitigation generally focuses on enforcing authentication and authorization at the service boundary, rather than relying on network location alone. Secure defaults include binding administrative or storage services to restricted interfaces, placing them behind an authenticated gateway, and denying unauthenticated access to every route. Access should be limited to the smallest set of trusted clients and operations, with separate permissions for reads, writes, deletion, and mounting. Network policies, segmentation, and least-privilege service identities can reduce exposure when direct access is unavoidable. Input validation and audit logging should also be applied to state-changing requests.
Mitigation generally focuses on enforcing authentication and authorization at the service boundary, rather than relying on network location alone. Secure defaults include binding administrative or storage services to restricted interfaces, placing them behind an authenticated gateway, and denying unauthenticated access to every route. Access should be limited to the smallest set of trusted clients and operations, with separate permissions for reads, writes, deletion, and mounting. Network policies, segmentation, and least-privilege service identities can reduce exposure when direct access is unavoidable. Input validation and audit logging should also be applied to state-changing requests.
How teams detect issues like this
Detection approaches include scanning service configuration for listeners bound to 0.0.0.0 or other broad interfaces, reviewing route registration for missing authentication middleware, and using static analysis or automated policy checks to identify unauthenticated administrative endpoints. Code reviews should examine whether every sensitive route performs authentication and operation-level authorization before processing input. Runtime monitoring can alert on unexpected clients, unauthenticated requests, bulk deletion, object injection, or mount activity.
Detection approaches include scanning service configuration for listeners bound to 0.0.0.0 or other broad interfaces, reviewing route registration for missing authentication middleware, and using static analysis or automated policy checks to identify unauthenticated administrative endpoints. Code reviews should examine whether every sensitive route performs authentication and operation-level authorization before processing input. Runtime monitoring can alert on unexpected clients, unauthenticated requests, bulk deletion, object injection, or mount activity.
