LMCache has a 9.8 with no patch: how to keep your inference cache off the network

By Eli - Published: 8 October 2026

There is a particular kind of advisory that is more awkward than a patch notice: the one where the vulnerability is public, the severity is 9.8, and the vendor's answer is "configure it differently". That is where LMCache sits this week. JFrog published CVE-2026-105192 on 7 October, and as The Hacker News reports, no fixed version exists. The details are in JFrog's advisory.

What LMCache is, and why it is probably in your cluster

LMCache stores the intermediate attention state of language model requests so that a server such as vLLM does not recompute it for every repeated prompt. If you run chat assistants or retrieval-heavy workloads with long shared prefixes, it can cut serving costs noticeably, which is why platform teams have been adopting it. Versions 0.3.9 through 0.5.5 are affected, as are the 0.5.6 release candidates and the development branch.

The flaw

It lives in the multiprocess mode, where the cache runs as its own server and the model workers talk to it over ZeroMQ. That socket has no authentication. One of the message types is deserialised with pickle, and the server decodes the arguments before it checks which type of message it has been sent. Anyone who can reach the port can send a message that runs their code with the privileges of the LMCache process, and on the official container images that is root.

The pattern will be familiar. Researchers described the same shape of problem in other inference frameworks last November under the name ShadowMQ, and JFrog notes it has not established whether LMCache shares code with those projects. It does not need to. An unauthenticated socket feeding a pickle loader is a bad design wherever it turns up.

How exposed are you?

Better than the headline suggests, if you left the defaults alone. The multiprocess server listens on localhost out of the box, and a cache embedded inside a single vLLM process does not open the port at all. The trouble starts when someone binds it to a routable address so that workers on other nodes can reach it, which is the normal move in multi-node deployments. LMCache's own example Kubernetes DaemonSet binds to every interface, and example manifests have a habit of being promoted to production unchanged.

There is also some noise to be aware of. On 6 October one GitHub account filed six more reports alleging cross-tenant cache access and command execution in other network services. Those rest on one person's proof-of-concept claims, with no CVE and no maintainer confirmation, so treat them as unverified. Separately, a vLLM denial-of-service bug, CVE-2026-105756, touches deployments that use the LMCache connector; it is fixed in vLLM 0.30.0.

What we would do today

• Find every place LMCache runs. Search manifests and Helm values for the multiprocess server and for the image, not just the pip requirements, because it often arrives as a transitive choice made by a platform template.
• Check the bind address and who can reach the port. Anything listening on 0.0.0.0 or a pod IP reachable from other namespaces needs to be pulled back to localhost or to a network policy that admits only your own inference workers.
• Run the process as a non-root user with a read-only filesystem and no mounted cloud credentials. This does not fix the bug, but it decides whether a hit stays inside the cache or reaches the rest of the cluster.
• Accept that a firewall narrows the risk without removing it. JFrog is clear that any host able to open a connection can run code, so a compromised sibling workload is enough.
• Look for evidence. JFrog offers no indicators, so the practical checks are unexpected child processes of the cache, outbound connections from the cache pod, and new files under its working directory.
• Watch the project's security advisories page. The maintainers have not published one yet.

The wider lesson is for whoever approves inference tooling. These components sit on the GPU nodes that finance has just paid a great deal for, they run as root, and they were written to be fast on a trusted network. Put them on your list of things that need an owner and a threat model, not just a benchmark. If you would like a second pair of eyes on an inference platform, write to sales@halfteck.com.