Critical Mooncake TCP Flaw Let Unauthenticated Peers Touch Process Memory

Between October 1 and 2, 2026, the published record for CVE-2026-103764 (GHSA-mp8g-r7h2-5x36) described a Critical defect in Mooncake’s transfer engine before version 0.3.13: an unauthenticated peer who can reach the TCP data port can read or write arbitrary process memory, including KV-cache contents, prompts, and secrets, or corrupt memory toward code execution. The CVE record, assigned by VulnCheck, scores the issue 9.8 on CVSS 3.1 and 9.3 on CVSS 4.0, maps it to untrusted pointer dereference (CWE-822), and credits Mingkai Yu and Jiajia Liu. Mooncake sits under disaggregated LLM serving as a KV-cache transfer layer, so a network-reachable transfer engine is an AI-infrastructure patch, not a side library.

Who is exposed

Affected builds are mooncake-transfer-engine from the start of the line through every release before 0.3.13. The vulnerable condition is reachability plus an old package: no account on the serving stack is required, and the CVE scores privileges as none. That is why a listener left on a shared network, a lab VLAN, or a multi-tenant GPU node is in scope even when the rest of the cluster looks internal. Process memory on these hosts is not an empty buffer. It holds KV blocks, prompt text, and whatever secrets the engine process can see. A read is a disclosure of that working set. A write is corruption of the same process, which the advisory treats as a path toward code execution, not only a crashed worker.

The public record stays at that impact level. Operators should take version, score, and reachability from the CVE and GitHub issue #4441, then patch. This note does not describe how a request is formed.

What 0.3.13 changes, and what it does not

The fixed line named by the CVE product status and by issue #4441 is 0.3.13 and later. That release confines transfers to memory the engine has already registered, so a reachable peer can no longer aim at arbitrary process memory. Upgrade to that version, or newer, and restart so old processes are gone. Tracking stays on the CVE, the GitHub advisory GHSA-mp8g-r7h2-5x36, and issue #4441. The v0.3.13 release notes are the version marker, not a substitute for the pin.

Issue #4441 also records the leftover boundary. Registered-buffer checks stop the arbitrary-memory path. They do not add authentication on the data port. A host on 0.3.13 can still accept transfer attempts against registered buffers from anyone who can open that port. Upgrade is necessary. Network policy is still required: keep the listener on trusted peers, and do not treat an internal data plane as a substitute for a firewall.

CISA’s enrichment on the CVE marks exploitation as a public proof of concept and the attack as automatable once the service is reachable. That is an inventory signal. It is not a reason to reconstruct the traffic or to treat a mirror write-up as an operator runbook.

What operators should do

Teams running Mooncake beside open serving stacks should find every host with the transfer engine installed, pin 0.3.13 or newer, and restart. PyPI will keep serving older wheels until constraints move, so an image rebuild that does not bump the pin does not close the issue. If a vulnerable listener was reachable during the window, rotate secrets that lived in that process and review whether prompts or cache state from that host should be treated as exposed.

Other Mooncake CVEs are separate advisories, including a distinct HTTP authentication issue, and should not be folded into 103764. Patching this TCP memory flaw does not clear those. This is also not the GitLab AI Gateway patch from the same week. Mooncake is shared transfer infrastructure under serving stacks, not a Duo control plane.

For Writeble’s cyber-security desk, CVE-2026-103764 is the Critical AI-infra item of the Oct 1–2 window: move past 0.3.13, then keep the data port inside a network trust boundary.