Mooncake Store EUVD-2026-93401

Exploitation requires network reachability to the Mooncake Store master's coro_rpc port, which performs no authentication on object-deletion RPCs (CWE-306); the attacker simply sets the force flag in Remove/RemoveByRegex/RemoveAll/BatchRemove requests to bypass the lease checks that would otherwise protect objects. No special non-default configuration, credentials, or user interaction is needed against affected versions (through 0.3.13.post1). The primary limiting factor is deployment topology: if the coro_rpc port is bound to localhost or isolated on a trusted backend network segment behind firewalling, remote exploitation is prevented, making network exposure of that port the decisive risk condition.

Multiple signals point to a genuine but availability-scoped risk rather than a critical compromise. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) confirms network-reachable, low-complexity, unauthenticated exploitation requiring no user interaction, which aligns cleanly with the CWE-306 (missing authentication) root cause and the description's claim that forged requests on the coro_rpc port bypass lease checks. Impact is deliberately narrow: VC:N (no confidentiality loss), VI:L (limited integrity - attacker deletes but cannot alter/forge data content), and VA:H (high availability impact from wiping the cache), so this is a data-destruction/denial-of-service issue, not code execution or data theft. No EPSS score, CISA KEV listing, or public POC is present in the input, so there is no evidence of active exploitation or automated weaponization - this is a disclosed-but-unproven-in-the-wild finding from VulnCheck. The practical priority is high only where a Mooncake Store master's coro_rpc port is exposed to untrusted networks; in a properly segmented LLM-serving backend the real-world exposure is much lower than the 8.8 base score suggests. No key signals conflict, but note the reliance on a single researcher source (VulnCheck/NVD) with no vendor advisory confirming fixed versions.

An attacker who can reach the Mooncake Store master's coro_rpc port over the network sends a forged Remove/RemoveByRegex/RemoveAll/BatchRemove request with the force flag set, bypassing lease checks without any authentication. This lets them delete arbitrary objects or clear the entire KV cache, causing cache misses, recomputation storms, and failed inference requests across the LLM-serving cluster. No public exploit identified at time of analysis, though the vulnerable code path is pinpointed in the referenced master_service.cpp source.