EUVD-2026-93400
GHSA-737v-cgc2-fgvf
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessReach exposed Store REST port (0.0.0.0)
-
DeliverySend unauthenticated /api request
-
ExploitCall /api/get, /api/put or /api/mount
-
ExecutionRead KV prompts, inject/delete or mount segments
-
ImpactData theft, cache poisoning, inference disruption
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V6 - Authentication Authentication required for critical functions
MITRE ATT&CK
1 technique across 1 tactic: Initial Access The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | The Mooncake Store REST service binds to 0.0.0.0 (all network interfaces) and enforces no authentication on any route, so exploitation requires only network reachability to the service's listening port - no credentials, tokens, or user interaction. The exposed routes (/api/get, /api/put, /api/remove_all, /api/mount) are directly callable. The primary limiting factor is network exposure: if the service port is confined to a trusted, segmented backend unreachable by untrusted hosts, practical exploitation is blocked; the risk is highest where the instance is reachable from a flat internal network or accidentally exposed to the internet. This affects default configurations since the bind-to-0.0.0.0-without-auth behavior is the shipped default through version 0.3.13.post1. |
| Impact | All available signals point to genuinely high real-world risk, though some key telemetry is absent. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N with VC:H/VI:H/VA:H, score 9.3) describes a network-reachable, low-complexity flaw needing no privileges or user interaction and yielding full confidentiality, integrity and availability impact on the vulnerable system - the worst realistic profile for exposure. This is corroborated by the description and CWE-306: the Store REST service binds to 0.0.0.0 with no authentication on any route, so the high score reflects a real design defect rather than a theoretical edge case. However, several decision-support signals are missing from the input: no EPSS probability was provided, the SSVC/CISA KEV status is absent (treat as not listed), and no public exploit code is referenced - so exploitation is 'no public exploit identified at time of analysis.' The practical risk hinges on network exposure: against any Mooncake Store instance reachable from an attacker (including flat internal networks or accidentally internet-exposed inference clusters), exploitation is trivial, but instances confined to a trusted, segmented backend are far less at risk. Net: a real, high-priority issue wherever the service is network-reachable, but prioritization should account for the missing EPSS/KEV data and the fact that impact is gated by whether the bound port is actually reachable by untrusted hosts. |
| Exploit ScenarioDerived | An attacker with network reachability to a Mooncake Store instance (which binds to 0.0.0.0 on all interfaces) directly calls the unauthenticated REST routes - for example /api/get to read cached KV data containing other users' LLM prompts, or /api/put and /api/remove_all to inject or delete cached objects. Because no authentication is required (PR:N) and complexity is low, this needs only an HTTP client and the service address; no public exploit code is identified at time of analysis, but the attack requires no special tooling. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 06, 2026
The Mooncake Store REST service through version 0.3.13.post1 binds to 0.0.0.0 and enforces no authentication on any route, so any host that can reach the service port can read cached KV data (including user prompts), inject or delete objects via /api/put and /api/remove_all, and mount attacker-described segments via /api/mount - all without credentials or user interaction (CVSS:4.0 9.3; independent assessment: CVSS:3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). Exposure is the shipped default in affected versions, making risk highest where the listener is reachable from a flat internal network or accidentally exposed to the internet; no public exploit code was identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV). This is a missing-authentication class defect (CWE-306), not a memory-safety or injection bug.
RemediationAI
No vendor-released patch was identified in the available data at time of analysis, so remediation should begin with containment. First, stop binding the Store REST service to 0.0.0.0 - configure it to listen only on a loopback or dedicated private interface and verify the effective bind address after restart; the trade-off is that legitimate remote workers must be re-pointed at the restricted address or a broker. Second, if remote access is genuinely required, place the service behind an authenticating reverse proxy or mTLS overlay and restrict the port with host/network firewall rules to known worker CIDRs; the trade-off is added proxy latency and certificate/token lifecycle management. Third, where the service cannot be restricted immediately, treat the network path as trusted-only: segment the cache subnet away from user-facing and general internal networks, and monitor for calls to /api/remove_all and /api/mount, which are high-signal abuse routes - a trade-off here is that segmentation can break co-located inference schedulers. Fourth, block inbound traffic to the Store REST port at the perimeter to prevent accidental internet exposure, and inventory any instances already reachable externally, treating them as potentially compromised (rotate data and audit cached prompts). Track the upstream project and advisory https://github.com/kvcache-ai/Mooncake/issues/4476 and https://www.vulncheck.com/advisories/mooncake-through-0.3.13-post1-missing-authentication-in-store-rest-service for a fixed release, and upgrade to the first tagged version that adds authentication rather than assuming a code push equals a patched package. Note that disabling individual routes reduces exposure but does not substitute for authentication if any read or write handler remains reachable; E:X/CR:X in the supplied CVSS 4.0 vector means environmental scoring was not provided, so operators should recompute risk against their own network exposure.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Mooncake is a KV-cache-centric, disaggregated serving architecture for LLM inference (kvcache-ai/Mooncake), where a distributed cache stores key/value tensors and metadata that inference workers read and write. The affected component is the Python-based Store REST service defined in mooncake-wheel/mooncake/mooncake_store_service.py (referenced lines 240-282), which registers operational endpoints such as /api/get, /api/put, /api/remove_all, and /api/mount but applies no authentication, authorization, or token check on any handler. The root cause is CWE-306 (Missing Authentication for Critical Function): the server socket is bound to 0.0.0.0, i.e., every network interface, and no credential gate exists at the application layer, so the only boundary between an attacker and full cache administration is network reachability. Because the cache holds prompt and KV state used by the inference pipeline, unauthenticated read access is a direct confidentiality problem (prompt/data leakage), while /api/put and /api/remove_all give integrity and availability impact through artifact poisoning or cache destruction, and /api/mount lets an attacker attach an externally described segment that the service will treat as its own storage. The publicly linked GitHub issue (kvcache-ai/Mooncake#4476) and the upstream source reference document the exposed route surface and bind behavior; no CPE strings or vendor advisory CVE mapping were supplied in the source data.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
No authentication on a network-bound REST service gives AV:N/AC:L/PR:N/UI:N; read, inject/delete and mount abilities map to C:H/I:H/A:H with scope unchanged.
Primary rating from Vendor (vulncheck).
CVSS VectorVendor: vulncheck
DescriptionCVE.org
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.
Executive ViewAI
The Mooncake Store REST service through version 0.3.13.post1 exposes sensitive cached data and allows unauthorized data manipulation, creating a critical risk for organizations that use this component. Because the service is accessible without authentication from any network host, attackers could read user prompts, alter or delete data, and mount malicious segments, potentially leading to data breaches or service integrity loss. With no vendor patch available and no public exploit code identified, leadership should act immediately to restrict network access and protect affected systems.
Restrict network access to the service port via firewall or network segmentation; bind the service to localhost (127.0.0.1) instead of 0.0.0.0; deploy an authenticating reverse proxy or API gateway; disable the REST service if not required; monitor for unauthorized access to /api/put, /api/remove_all, and /api/mount endpoints.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Exploit-DB