Submit #904600: kvcache-ai Mooncake >= 0.3.4, <= 0.3.12 Authorization Bypass

Mooncake Store Master does not verify that the supplied `client_id` owns the supplied `segment_id` before processing the immediate `UnmountSegment(segment_id, client_id)` RPC. A network peer that can reach the Master RPC endpoint can therefore submit a victim's segment ID with an attacker-controlled client ID. The Master removes the victim segment's allocator, cleans related object-replica metadata, and erases the victim segment from the global mount table.

The newer `GracefulUnmountSegment` path explicitly checks this ownership relationship and rejects the same cross-client request. The immediate path does not.

In Mooncake v0.3.12, the Master admin HTTP endpoint `GET /get_segments_detail` discloses the identifiers needed for exploitation. Its handler returns every registered `segment_id` and `client_id` without performing an authentication check. By default, the Master binds RPC to `x.x.x.x` on port `50051` and starts the admin HTTP server on port `9003`. When both control-plane ports are reachable, these behaviors form an unauthenticated cross-client segment-deletion chain.

The core cross-client unmount behavior was dynamically reproduced with the `mooncake-transfer-engine==0.3.11.post1` wheel. The same vulnerable path and the identifier-disclosure endpoint were confirmed by source inspection in v0.3.12. The vulnerable path was also present in the `main` branch at commit `a1ca71f42a2c7fc708d74d5314bf576dfde9ad8f`, inspected on 2026-07-24. The complete v0.3.12 HTTP-to-RPC chain has not been rerun dynamically.

• Source: ⚠️ https://gist.github.com/yyymk/76d099537af0e661dd01eacc82b9a7ea
• User: YYYMK (UID 100105)
• Submission: 07/24/2026 20:11 (2 months ago)
• Moderation: 09/23/2026 18:01 (2 months later)
• Status: Accepted
• VulDB entry: 409016 [kvcache-ai mooncake up to 0.3.12/0.3.13.post1 RPC Path UnmountSegment client_id/segment_id authorization]
• Points: 20