LMCache’s KV-Cache Servers Carry Five Unauthenticated-Access CVEs and No Fixed Release Yet

Five CVEs published on October 7, 2026 cover missing authentication in LMCache, the open-source KV-cache layer used with LLM serving engines. Two allow remote code execution and carry 9.8 CVSS 3.1 scores. No patched release exists, so operators have to rely on network isolation for now.

An LLM key-value cache cluster with unauthenticated network ports exposed to untrusted peers
An LLM key-value cache cluster with unauthenticated network ports exposed to untrusted peers

Five CVEs published on October 7, 2026 describe missing authentication across several network services in LMCache, the open-source KV-cache layer that sits beside LLM serving engines. Two of the five lead to remote code execution, and both carry CVSS 3.1 scores of 9.8. As of October 7, no fixed release had been published. LMCache describes itself as “the Fastest KV Cache Layer” for LLMs. Its Apache-2.0 GitHub repository had about 12,000 stars at the time of writing.

The batch comes from two separate disclosures. JFrog Security Research, acting as CNA, published CVE-2026-105192 at 09:40 UTC. VulnCheck followed at 15:24 UTC with CVE-2026-107204 through CVE-2026-107207. Each of those four records cites a GitHub issue opened in LMCache’s public tracker on October 6, and all four issues were still open when this was written.

A pickle on the distributed transport

CVE-2026-105192 affects LMCache’s multiprocess mode, which the project also calls distributed mode. In this mode, LMCache opens a ZeroMQ socket, by default on port 5555, so worker processes can register and share KV-cache blocks. JFrog says the socket has no CURVE, ZAP, password or message authentication. Part of the incoming message is passed to Python’s pickle deserializer while the server is still decoding the request, before any handler runs. A single unauthenticated message can therefore run code as the user the LMCache process runs under. JFrog notes that the official container images run that process as root.

JFrog scores the flaw 9.8 for one specific setup. The transport binds to localhost unless an operator passes a routable address with --host, which is how multi-node deployments let peers connect. A stock single-host install that keeps the default bind is not reachable from other machines, and LMCache running only inside a vLLM process does not open the port at all. The affected code first shipped in v0.3.9. JFrog says it is still present in v0.5.5, the latest PyPI release, in the v0.5.6 release candidates through rc3, and on the development branch as of October 7. Yuval Moravchick of JFrog is credited with the finding.

Four control planes without a login

The VulnCheck records, credited to Mingkai Yu and Jiajia Liu, all list LMCache through 0.5.5 as affected and all cite CWE-306, missing authentication for a critical function.

  • CVE-2026-107204 (CVSS 4.0 9.3, CVSS 3.1 9.8). The internal API server’s /run_script endpoint runs caller-supplied Python inside a restricted sandbox that can be escaped, which leads to operating-system commands. The linked issue says this server is opt-in and disabled by default, but binds to all interfaces when enabled.
  • CVE-2026-107205 (4.0: 8.8, 3.1: 8.6). The multiprocess coordinator’s fleet-control API listens on all interfaces by default. An attacker can register or remove cache instances, overwrite quotas, inject events, and list key placement.
  • CVE-2026-107206 (4.0: 8.8, 3.1: 9.4). The multiprocess HTTP management server exposes environment variables and configuration through unauthenticated endpoints. It also lets callers clear caches, delete objects, and change other tenants’ quotas.
  • CVE-2026-107207 (4.0: 6.9, 3.1: 7.2). The frontend monitoring service lets unauthenticated callers register arbitrary hosts in its proxy catalog. That defeats the proxy allowlist and turns the service into a server-side request forgery relay.

Why a cache layer is a high-value target

KV caches hold the intermediate attention state for prompts that a serving cluster has already processed, so they can be reused across requests and machines. That cross-node sharing is what LMCache is for, and it is also why these services listen on the network. The impact runs from full host takeover to quieter harms: leaked credentials from a process environment, one tenant evicting another’s cached data, and a cache fleet’s placement metadata exposed to anyone who can reach the port.

NVD listed CVE-2026-105192 as Deferred and CVE-2026-107204 as Received at the time of writing. Neither had an NVD score of its own.

What operators can do before a patch

With no fixed version available, mitigation comes down to exposure. JFrog advises against setting --host to a routable address and recommends keeping the multiprocess port on localhost or a trusted cluster network. It warns that a firewall narrows who can connect, but any host that can still open a connection can run code as the LMCache user.

Operators should also check which LMCache services they actually run. The coordinator, management, internal API and frontend components should be bound to loopback or a private segment, or placed behind an authenticating proxy, and the internal API server should stay disabled unless it is needed. Running LMCache as a non-root user limits the damage from a successful attack. For the upstream fix, JFrog recommends replacing pickle on that transport with a safe serializer and authenticating ZeroMQ peers, for example with CURVE or a per-message HMAC.

Topics
  • #Cybersecurity
  • #LMCache
  • #LLM Inference
  • #CVE
  • #AI Infrastructure
Raj M

Author

Raj M

Contributor

AI Systems Architect is a seasoned technology leader with over 15 years of experience in the IT industry working with Fortune 500 companies. With a solid foundation in multi-agent systems, open-source LLM infrastructure, and enterprise deployment, he excels at building scalable production-grade AI platforms.