← All insights
Your CTO Advisor15 Oct 2026

Your KV cache tier trusts the whole network. Seven October CVEs say it shouldn't

By Avinash Kumar Dubey ·

Your KV cache tier trusts the whole network. Seven October CVEs say it shouldn't

In the first two weeks of October, seven CVEs landed in the two open-source projects many teams use to share LLM KV cache across GPUs and servers: LMCache and Mooncake. Six are rated 9.4 or higher, every one is reachable without credentials, and the worst lets a single ZeroMQ message run code as root (on the official images) on the box that sits next to your GPUs and holds data derived from your users' prompts.

AG Tech Consulting's advice for clients this week: inventory every KV cache and inference-transport service you run (LMCache, Mooncake, anything on port 5555), confirm none binds a routable address without authentication, upgrade LMCache to 0.5.6 with workers and servers together, firewall Mooncake's Store REST and metadata services, and treat any host whose cache port was reachable from an untrusted network as potentially compromised.

What was disclosed

LMCache is a KV cache management layer for LLM inference. It stores and reuses the attention key/value cache a model builds during prefill, so repeated context (RAG documents, long system prompts, multi-turn history) does not have to be recomputed. It plugs into serving engines such as vLLM and SGLang, NVIDIA Dynamo integrates it, and the project joined the PyTorch Foundation in October 2025. Mooncake (kvcache-ai/Mooncake) provides a transfer engine and distributed store that moves the same KV data between nodes, and LMCache lists it as a supported storage backend.

That makes the cache tier the most trusted, least inspected part of many inference stacks. October's disclosures show what happens when its internal protocols meet a real network.

LMCache CVE-2026-105192: one ZeroMQ frame, code as root

JFrog Security Research (finder: Yuval Moravchick) disclosed CVE-2026-105192 on 7 October, CVSS 3.1 9.8. In multiprocess mode, also called distributed mode, LMCache opens a ZeroMQ ROUTER socket (default port 5555) so worker processes can register and share KV cache blocks. There is no CURVE, ZAP, password or message authentication on that socket.

Messages are msgpack. Extension code 1 is registered for DeviceIPCWrapper, and DeviceIPCWrapper.Deserialize calls pickle.loads. That hook fires inside ext_hook while the server is still decoding REGISTER_KV_CACHE arguments, before any handler runs. One unauthenticated DEALER message carrying a crafted pickle executes code as the LMCache user; JFrog's proof of concept returns uid=0(root) on the official images.

The transport binds to localhost by default, and LMCache running inside a single vLLM process does not open the port. The exposure is the multi-node setting: an operator passes --host with a routable address so peers can connect. LMCache's own example Kubernetes deployment bound all interfaces, so the maintainers say anyone who based a deployment on it should assume exposure. Affected versions run from 0.3.9 (October 2025) through 0.5.5 and the 0.5.6 release candidates.

LMCache CVE-2026-107204, -107206, -107205: the HTTP side

The same day, three more LMCache CVEs credited to Mingkai Yu and Jiajia Liu were published with VulnCheck advisories, all affecting releases through 0.5.5:

CVE-2026-107204 (9.8). The /run_script endpoint accepts Python scripts over HTTP with no authentication. The script runs under a guarded import, but an attacker can recover the real builtins through the injected FastAPI app object, import os and run operating-system commands as the LMCache process.

CVE-2026-107206 (9.4). The multiprocess HTTP server's management endpoints listen on all interfaces by default with no authentication. GET /env returns environment credentials and GET /config returns configuration; callers can also clear caches, delete cache objects and change tenant quotas to evict other tenants' cached data.

CVE-2026-107205 (8.6). The multiprocess coordinator's fleet control API also listens on all interfaces by default. Unauthenticated callers can register or deregister instances via /instances, overwrite /quota settings, inject /events and enumerate /directory/keys to disclose placement metadata.

Mooncake CVE-2026-103764, -103765, -106037

The same researchers are credited on three Mooncake CVEs published between 1 and 6 October.

CVE-2026-103764 (9.8). Before 0.3.13, the transfer engine's TCP data port trusted the addr and size fields in a SessionHeader. ServerSession::readHeader treated addr as a raw process pointer, so an unauthenticated peer could READ or WRITE arbitrary process memory: KV cache contents, prompts and secrets, or corruption toward code execution. Fixed in 0.3.13.

CVE-2026-103765 (9.4). The HTTP metadata server's /metadata handler lets unauthenticated callers read, overwrite and delete transfer-engine metadata keys. Poisoning a segment descriptor such as tcp_data_port, or re-creating rpc_meta entries, redirects KV cache transfers to an attacker-controlled listener.

CVE-2026-106037 (9.8). The Store REST service binds to 0.0.0.0 with no authentication on any route. /api/get reads cached KV data that contains user prompts; /api/put, /api/remove_all and /api/mount inject or delete objects and mount attacker-described segments.

Both CVE records list affected versions through 0.3.13.post1, which was still the latest mooncake-transfer-engine release on PyPI on the morning of 15 October.

And a vLLM crash on the same seam

vLLM fixed CVE-2026-105756 (6.5) in 0.30.0. Before that release, OpenAI-compatible requests accepted a cache_salt value without the character and length rules that LMCache-MP's IPCCacheServerKey requires. On deployments using the LMCache-MP connector, one request with a bad salt raised an uncaught ValueError during scheduler cache lookup and terminated EngineCore for every concurrent user. It is denial of service, not code execution, but it is the same lesson: data crossing from the API layer into the cache layer was not validated at the boundary.

How an attacker reaches the KV cache tier: in multi-node deployments, LMCache's ZeroMQ transport (port 5555) and HTTP management APIs and Mooncake's Store REST, metadata and TCP data services accept unauthenticated traffic, enabling code execution (CVE-2026-105192, CVE-2026-107204), credential leaks (CVE-2026-107206), memory read/write (CVE-2026-103764), transfer redirection (CVE-2026-103765) and prompt-data reads (CVE-2026-106037). The defended path binds these services to localhost or a private segment, requires identity on every hop, and runs LMCache 0.5.6 as non-root.
How an attacker reaches the KV cache tier: in multi-node deployments, LMCache's ZeroMQ transport (port 5555) and HTTP management APIs and Mooncake's Store REST, metadata and TCP data services accept unauthenticated traffic, enabling code execution (CVE-2026-105192, CVE-2026-107204), credential leaks (CVE-2026-107206), memory read/write (CVE-2026-103764), transfer redirection (CVE-2026-103765) and prompt-data reads (CVE-2026-106037). The defended path binds these services to localhost or a private segment, requires identity on every hop, and runs LMCache 0.5.6 as non-root.

How an attacker reaches the KV cache tier: in multi-node deployments, LMCache's ZeroMQ transport (port 5555) and HTTP management APIs and Mooncake's Store REST, metadata and TCP data services accept unauthenticated traffic, enabling code execution (CVE-2026-105192, CVE-2026-107204), credential leaks (CVE-2026-107206), memory read/write (CVE-2026-103764), transfer redirection (CVE-2026-103765) and prompt-data reads (CVE-2026-106037). The defended path binds these services to localhost or a private segment, requires identity on every hop, and runs LMCache 0.5.6 as non-root.

Why the cache tier is a high-value target

A KV cache server sits on the same network as the model servers, often with GPU memory, RDMA or NVLink paths and storage credentials close by. It holds tensors derived from every prompt it caches, including system prompts, retrieved documents and conversation history. In multi-tenant setups it also enforces quota and isolation between tenants.

Code execution there is a foothold in the most expensive and most sensitive part of an AI deployment. Read access is a prompt-data breach. Write access is subtler: an attacker who can put, poison or redirect cache objects can influence what other users' requests reuse.

What got fixed, and what did not

LMCache 0.5.6. The GitHub release was published on 14 October (UTC), after the maintainers merged PR #5644 into dev on 12 October and published advisory GHSA-w5f2-9q9c-ff4h on 13 October. Pickle is replaced with versioned, typed MessagePack descriptors that are validated before use; the device wrapper type comes from a fixed local allowlist, with no pickle fallback, on both ZeroMQ and gRPC paths. The /run_script endpoint is now disabled by default, the admin HTTP server binds to localhost, the example Kubernetes manifests bind to localhost (PR #5684) and official images run as non-root (PR #5685). The wire format changed, so workers and servers must be upgraded together.

Still open. On the morning of 15 October, PyPI still listed 0.5.5 as the latest stable lmcache, and the /run_script sandbox-escape issue (#5510) was still open on GitHub; 0.5.6 switches the endpoint off rather than making it safe to switch on. LMCache says RPC between the server, the multiprocess coordinator and the frontend is still unauthenticated, with authentication planned for 0.5.7, and that pickle on the engine-driven path (disabled by default, not network-reachable) is planned for removal before 0.5.8. Mooncake's metadata and Store REST CVEs list no fixed release.

Checking for compromise. LMCache's own guidance is blunt: exploitation happens before the message is processed, so a rejected or malformed request in your logs does not mean the attack failed. If the port was reachable from an untrusted network, review connections to it, look for unexpected child processes, shells or outbound connections from the LMCache process, rotate reachable credentials and redeploy from clean images.

This is ShadowMQ again

In November 2025, Oligo Security's ShadowMQ research showed the same root cause, pickle deserialization over unauthenticated ZeroMQ TCP sockets, copied across Meta Llama Stack (CVE-2024-50050), vLLM (CVE-2025-30165), NVIDIA TensorRT-LLM (CVE-2025-23254) and Modular Max Server (CVE-2025-60455). Oligo traced it to code reuse between projects and reported thousands of ZeroMQ sockets exposed to the public internet. Whether LMCache's code shares a source with those projects has not been established, but the pattern is the same: performance plumbing designed for one trusted cluster, deployed onto shared networks.

Future security risks to plan for

1. Cache poisoning across tenants. Put and mount primitives on a shared cache can plant objects that other users' requests reuse. Expect research on poisoned KV blocks that change model outputs without touching weights or prompts.

2. Prompt-data leakage from cache stores. Cached KV tensors are derived from prompts. Treat cache tiers, their L2 storage backends and their snapshots as regulated data stores, not scratch space.

3. Transfer redirection in disaggregated serving. Prefill/decode disaggregation moves KV data over the network by design. Metadata poisoning of the CVE-2026-103765 kind turns that into silent exfiltration.

4. Inherited serialization flaws. ShadowMQ and CVE-2026-105192 show the same unsafe pattern recurring. Every new inference component you adopt can bring its own pickle, its own 0.0.0.0 default and its own root container.

5. GPU hosts as crypto-mining and pivot targets. A root shell next to the GPUs is valuable on its own. Expect opportunistic scanning for 5555 and similar inference ports.

6. Unauthenticated control planes. Coordinator, quota and fleet APIs are being added fast. Until RPC authentication ships in LMCache 0.5.7 and Mooncake adds route authentication, the network is the only control.

A 10-point checklist for CTOs

Inventory every LMCache, Mooncake and other KV cache or inference-transport service in your clusters, including ones started automatically by the vLLM connector. Scan internal and cloud networks for listeners on LMCache's transport port (5555 by default) and on LMCache and Mooncake HTTP management ports; anything bound to 0.0.0.0 is a finding. Upgrade LMCache to 0.5.6 across all workers and servers in one change window; the wire format changed and mixed versions are not supported. Pin images that run as non-root, and remove any deployment derived from the old all-interfaces Kubernetes example. Keep /run_script disabled and block the path at any ingress or proxy, because the upstream sandbox-escape issue is still open. Put Mooncake's Store REST service and HTTP metadata server behind network policy or an authenticating proxy, and upgrade the transfer engine to at least 0.3.13. Upgrade vLLM to 0.30.0 or later wherever the LMCache-MP connector is in use. Rotate any secret visible through LMCache's /env endpoint or present in the cache process environment on hosts that were reachable. Treat exposed hosts as potentially compromised: check for unexpected child processes, shells and outbound connections from cache processes, then redeploy from clean images. Classify KV cache stores and their storage backends as containing prompt data, with the same retention, encryption and access controls as your RAG corpus and chat logs.

The bottom line

The KV cache tier was built to make inference fast inside one trusted cluster. October's LMCache and Mooncake CVEs show that, on a shared network, it is an unauthenticated code-execution and prompt-data service sitting next to your GPUs. Patch LMCache to 0.5.6, wall off what is not patched, and give the cache tier the same identity, isolation and data-classification rules you already apply to your databases.

Sources: JFrog Security Research, JFSA-2026-001694382, LMCache unauthenticated RCE via pickle deserialization on the multiprocess ZMQ transport (CVE-2026-105192), 7 Oct 2026 (https://research.jfrog.com/vulnerabilities/lmcache-is-vulnerable-to-unauthenticated-remote-code-execution-via-pickle-deserialization-on-the-multiprocess-zmq-transport-cve-2026-105192-jfsa-2026-001694382/); LMCache advisory GHSA-w5f2-9q9c-ff4h, 13 Oct 2026 (https://github.com/LMCache/LMCache/security/advisories/GHSA-w5f2-9q9c-ff4h); LMCache Team, "An Update on CVE-2026-105192," 13 Oct 2026 (https://blog.lmcache.ai/en/2026/10/13/an-update-on-cve-2026-105192/); LMCache v0.5.6 release notes (https://github.com/LMCache/LMCache/releases); CVE records CVE-2026-107204, CVE-2026-107206, CVE-2026-107205, CVE-2026-103764, CVE-2026-103765, CVE-2026-106037 and CVE-2026-105756 (https://www.cve.org/CVERecord?id=CVE-2026-107204 and matching IDs); VulnCheck advisory for CVE-2026-107204 (https://www.vulncheck.com/advisories/lmcache-through-0.5.5-unauthenticated-rce-via-run-script-endpoint); The Hacker News, "Unpatched Critical LMCache Flaw Lets Unauthenticated Attackers Run Code Remotely," 7 Oct 2026 (https://thehackernews.com/2026/10/unpatched-critical-lmcache-flaw-lets.html); NetFoundry Reachability Watch, 9 Oct 2026 (https://netfoundry.io/ai/reachability-watch-cve-kev-tracker-2026-10-09/); Oligo Security, "ShadowMQ," 13 Nov 2025 (https://www.oligo.security/blog/shadowmq-how-code-reuse-spread-critical-vulnerabilities-across-the-ai-ecosystem).

Want help auditing your inference and KV cache tier before the next disclosure? Email avinash@agtechconsulting.ai, visit agtechconsulting.ai, or book a 30-minute call: https://calendly.com/avinash-dubey-30-min-catchup/meeting-with-ag-tech

Originally published on LinkedIn in the Your CTO Advisor newsletter: read and comment on LinkedIn →

Get Your CTO Advisor in your feed

Subscribe on LinkedIn for the next issue.

Subscribe on LinkedIn