[GH-ISSUE #4626] Security concern: 3 of 4 publicly-disclosed CVEs in Transfer Engine still unpatched in v0.3.13.post1 (handshake DoS, memory exhaustion, missing auth on /metadata) #1179

New issue

Open

opened 2026-10-29 21:23:39 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-29 21:23:39 +00:00

Owner

Originally created by @sivabreddy on GitHub (Oct 13, 2026).
Original GitHub issue: https://github.com/kvcache-ai/Mooncake/issues/4626

We were evaluating Mooncake for a production deployment and found four publicly-disclosed
CVEs against the Transfer Engine. One is already fixed; three appear to still be open as of the
latest release, with no public acknowledgement on this repo's Security Advisories page. Raising
this directly since it changes our evaluation, and we couldn't find an existing issue tracking it.

What we checked, and how

Verified directly via the CVE records themselves (not a single secondhand source), then
cross-checked against this repo's own releases page and Security Advisories page.

This repo's Security Advisories page currently lists nothing at all ("There aren't any
published security advisories") — these four CVEs don't appear to have been disclosed through
that channel.
Latest release is v0.3.13.post1 (2026-08-31). Its changelog does not mention any of the
four CVEs below.

The four CVEs

CVE	Component	What an attacker can do, with no login	Severity	Status as of 2026-10-13
CVE-2026-103764	`ServerSession::readHeader`, TCP transport data port	Send a crafted header with arbitrary address/size using READ or WRITE opcodes — read or write arbitrary process memory. Can disclose KV cache contents, prompts, and secrets, or corrupt memory toward code execution.	9.3 Critical	Fixed, in 0.3.12/0.3.13.
CVE-2026-103765	HTTP metadata server, `/metadata` handler	Read, overwrite, or delete the transfer engine's routing metadata with no authentication at all — e.g. rewrite `tcp_data_port` to redirect KV cache transfers to a machine the attacker controls, or exhaust server memory.	8.8 High	Still open in the latest release (`through 0.3.13.post1`).
CVE-2026-103760	`SocketHandShakePlugin`, handshake RPC port	Send a metadata request and never read the reply, stalling the single listener thread inside `writeFully()` — breaks all subsequent handshakes, metadata fetches, notify, and probe requests for the whole process.	8.2 High	Still open in the latest release (`through 0.3.13.post1`).
CVE-2026-103761	`TransferMetadata::receivePeerNotify`	Repeatedly send notify frames (up to 1MB each) to the handshake RPC port — fills an uncapped internal vector until the OS out-of-memory killer terminates the whole engine.	7.5 High	Still open in the latest release (`through 0.3.13.post1`).

Sources: opencve.io/CVE-2026-103760,
opencve.io/CVE-2026-103761,
opencve.io/CVE-2026-103764,
opencve.io/CVE-2026-103765,
vulncheck.com advisory for CVE-2026-103765,
Mend.io CVE-2026-103764.

Why this matters

All three still-open issues require only unauthenticated network access to the handshake RPC
port or the HTTP metadata port — no credentials, no prior foothold beyond network reachability.
In a shared Kubernetes cluster, that means any other workload on the same network segment (not
just a deliberate external attacker) could, in principle, knock the whole Transfer Engine
offline (CVE-2026-103760, -103761) or silently redirect its cache traffic to an unintended
destination (CVE-2026-103765).

What we're asking

Confirm whether CVE-2026-103760, -103761, and -103765 are already tracked internally, even
though nothing is visible on the public Security Advisories page.
Share a rough timeline or branch to watch for fixes, if one exists.
Confirm our reading of CVE-2026-103764's fix (0.3.12/0.3.13) is correct, and whether there is
a recommended minimum version once the other three are fixed.

Happy to provide more detail if useful.

Originally created by @sivabreddy on GitHub (Oct 13, 2026). Original GitHub issue: https://github.com/kvcache-ai/Mooncake/issues/4626 We were evaluating Mooncake for a production deployment and found four publicly-disclosed CVEs against the Transfer Engine. One is already fixed; three appear to still be open as of the latest release, with no public acknowledgement on this repo's Security Advisories page. Raising this directly since it changes our evaluation, and we couldn't find an existing issue tracking it. ## What we checked, and how Verified directly via the CVE records themselves (not a single secondhand source), then cross-checked against this repo's own releases page and Security Advisories page. - **This repo's Security Advisories page currently lists nothing at all** ("There aren't any published security advisories") — these four CVEs don't appear to have been disclosed through that channel. - **Latest release is `v0.3.13.post1` (2026-08-31)**. Its changelog does not mention any of the four CVEs below. ## The four CVEs | CVE | Component | What an attacker can do, with no login | Severity | Status as of 2026-10-13 | |---|---|---|---|---| | CVE-2026-103764 | `ServerSession::readHeader`, TCP transport data port | Send a crafted header with arbitrary address/size using READ or WRITE opcodes — read or write **arbitrary process memory**. Can disclose KV cache contents, prompts, and secrets, or corrupt memory toward code execution. | 9.3 Critical | **Fixed**, in 0.3.12/0.3.13. | | CVE-2026-103765 | HTTP metadata server, `/metadata` handler | Read, overwrite, or delete the transfer engine's routing metadata with no authentication at all — e.g. rewrite `tcp_data_port` to redirect KV cache transfers to a machine the attacker controls, or exhaust server memory. | 8.8 High | **Still open** in the latest release (`through 0.3.13.post1`). | | CVE-2026-103760 | `SocketHandShakePlugin`, handshake RPC port | Send a metadata request and never read the reply, stalling the single listener thread inside `writeFully()` — breaks all subsequent handshakes, metadata fetches, notify, and probe requests for the whole process. | 8.2 High | **Still open** in the latest release (`through 0.3.13.post1`). | | CVE-2026-103761 | `TransferMetadata::receivePeerNotify` | Repeatedly send notify frames (up to 1MB each) to the handshake RPC port — fills an uncapped internal vector until the OS out-of-memory killer terminates the whole engine. | 7.5 High | **Still open** in the latest release (`through 0.3.13.post1`). | Sources: [opencve.io/CVE-2026-103760](https://app.opencve.io/cve/CVE-2026-103760), [opencve.io/CVE-2026-103761](https://app.opencve.io/cve/CVE-2026-103761), [opencve.io/CVE-2026-103764](https://app.opencve.io/cve/CVE-2026-103764), [opencve.io/CVE-2026-103765](https://app.opencve.io/cve/CVE-2026-103765), [vulncheck.com advisory for CVE-2026-103765](https://www.vulncheck.com/advisories/mooncake-through-0.3.13-post1-missing-authentication-in-http-metadata-server), [Mend.io CVE-2026-103764](https://www.mend.io/vulnerability-database/CVE-2026-103764/). ## Why this matters All three still-open issues require only unauthenticated network access to the handshake RPC port or the HTTP metadata port — no credentials, no prior foothold beyond network reachability. In a shared Kubernetes cluster, that means any other workload on the same network segment (not just a deliberate external attacker) could, in principle, knock the whole Transfer Engine offline (CVE-2026-103760, -103761) or silently redirect its cache traffic to an unintended destination (CVE-2026-103765). ## What we're asking 1. Confirm whether CVE-2026-103760, -103761, and -103765 are already tracked internally, even though nothing is visible on the public Security Advisories page. 2. Share a rough timeline or branch to watch for fixes, if one exists. 3. Confirm our reading of CVE-2026-103764's fix (0.3.12/0.3.13) is correct, and whether there is a recommended minimum version once the other three are fixed. Happy to provide more detail if useful.

bsakaguchi commented

2026-10-29 21:23:39 +00:00

Author

Owner

@github-actions[bot] commented on GitHub (Oct 13, 2026):

Thanks for opening this issue, @sivabreddy!

Field	Value
Issue	#4626
GitHub user ID	`113816799`
Reporter	@sivabreddy

A maintainer will triage this when possible. To help us respond faster, please include:

Mooncake version or commit SHA
Environment (OS, CUDA/driver, RDMA stack if relevant)
Steps to reproduce and expected vs. actual behavior

Useful links: Documentation · Contributing guide

This message was posted automatically by the issue bot.

@github-actions[bot] commented on GitHub (Oct 13, 2026): Thanks for opening this issue, @sivabreddy! | Field | Value | |-------|-------| | **Issue** | #4626 | | **GitHub user ID** | `113816799` | | **Reporter** | @sivabreddy | A maintainer will triage this when possible. To help us respond faster, please include: - Mooncake version or commit SHA - Environment (OS, CUDA/driver, RDMA stack if relevant) - Steps to reproduce and expected vs. actual behavior Useful links: [Documentation](https://kvcache-ai.github.io/Mooncake/) · [Contributing guide](https://github.com/kvcache-ai/Mooncake/blob/main/CONTRIBUTING.md) > This message was posted automatically by the issue bot.

bsakaguchi commented

2026-10-29 21:23:40 +00:00

Author

Owner

@he-yufeng commented on GitHub (Oct 14, 2026):

Thanks for the careful write-up, and for cross-checking the CVE records against our release page directly. Maintainer answer with commit-level pointers, in your table's order:

CVE-2026-103764 (crafted header → arbitrary memory read/write): confirmed fixed, your reading is correct. The server session validates the remote-supplied address and size against registered buffers before touching them (validate_addr_). In the 0.3.12 line that check lives in tcp_transport.cpp; after #2974 it moved into tcp_transport_session_impl.h. Present in v0.3.12.post1 and everything since, including v0.3.13.post1.

CVE-2026-103765 (no auth on the HTTP metadata server): fix in review, not yet merged. #4472 adds optional bearer auth plus request/store bounds to the /metadata server. It is going through review right now, so no release carries it yet.

CVE-2026-103760 (stalled peer wedges the handshake listener): fixed on main, not yet released. #4451 puts SO_SNDTIMEO on accepted handshake sockets so writeFully() can no longer spin forever against a peer that never reads (commit 66bf7412, merged 2026-10-12).

CVE-2026-103761 (notify flood → OOM): fixed on main, not yet released. #4453 bounds the pending-notify queue that receivePeerNotify appends to (commit 38ee4194, merged 2026-10-10).

One nuance that matters for your evaluation: v0.3.14-rc1 (cut 2026-09-07) predates all three of these fixes, so the rc is not covered either. The first tag that will carry them is the v0.3.14 stable release.

To your three questions:

Nothing was tracked publicly here before; this issue is now the public record for the three open ones.
Branch to watch is main: #4451 and #4453 are already in, #4472 should land in the same window. The tag to wait for is v0.3.14 stable.
For 103764 alone, v0.3.12.post1 or later is safe. Until v0.3.14 ships with the other three, the practical mitigation is network-level: keep the handshake RPC port and the HTTP metadata port on an isolated segment, since the engine assumes a trusted network today.

Housekeeping on our side: the Security Advisories page is empty because nobody ever published GHSAs for these. I will propose to the other maintainers that we publish advisories when the v0.3.14 release carrying the fixes goes out, so the public record lines up with the CVE entries. @stmatengss for visibility on the release and advisory sequencing.

@he-yufeng commented on GitHub (Oct 14, 2026): Thanks for the careful write-up, and for cross-checking the CVE records against our release page directly. Maintainer answer with commit-level pointers, in your table's order: **CVE-2026-103764 (crafted header → arbitrary memory read/write): confirmed fixed, your reading is correct.** The server session validates the remote-supplied address and size against registered buffers before touching them (`validate_addr_`). In the 0.3.12 line that check lives in `tcp_transport.cpp`; after #2974 it moved into `tcp_transport_session_impl.h`. Present in v0.3.12.post1 and everything since, including v0.3.13.post1. **CVE-2026-103765 (no auth on the HTTP metadata server): fix in review, not yet merged.** #4472 adds optional bearer auth plus request/store bounds to the `/metadata` server. It is going through review right now, so no release carries it yet. **CVE-2026-103760 (stalled peer wedges the handshake listener): fixed on main, not yet released.** #4451 puts `SO_SNDTIMEO` on accepted handshake sockets so `writeFully()` can no longer spin forever against a peer that never reads (commit 66bf7412, merged 2026-10-12). **CVE-2026-103761 (notify flood → OOM): fixed on main, not yet released.** #4453 bounds the pending-notify queue that `receivePeerNotify` appends to (commit 38ee4194, merged 2026-10-10). One nuance that matters for your evaluation: v0.3.14-rc1 (cut 2026-09-07) predates all three of these fixes, so the rc is not covered either. The first tag that will carry them is the v0.3.14 stable release. To your three questions: 1. Nothing was tracked publicly here before; this issue is now the public record for the three open ones. 2. Branch to watch is main: #4451 and #4453 are already in, #4472 should land in the same window. The tag to wait for is v0.3.14 stable. 3. For 103764 alone, v0.3.12.post1 or later is safe. Until v0.3.14 ships with the other three, the practical mitigation is network-level: keep the handshake RPC port and the HTTP metadata port on an isolated segment, since the engine assumes a trusted network today. Housekeeping on our side: the Security Advisories page is empty because nobody ever published GHSAs for these. I will propose to the other maintainers that we publish advisories when the v0.3.14 release carrying the fixes goes out, so the public record lines up with the CVE entries. @stmatengss for visibility on the release and advisory sequencing.

bsakaguchi referenced this issue

2026-10-29 21:32:25 +00:00

[PR #1179] [MERGED] [TE/Examples] Memory initialization and HIP cleanup fixes #2053