LMCache RCE flaw leaves routable multiprocess servers at risk

JFrog has disclosed CVE-2026-105192, a critical vulnerability in LMCache that can let an unauthenticated attacker execute code remotely on an exposed multiprocess cache server. The flaw has a CVSS score of 9.8 when the server is bound to a routable address, and no fixed LMCache version is available.

The issue affects LMCache 0.3.9 through the latest stable release, 0.5.5, as well as 0.5.6 release candidates and the development branch. LMCache is open-source software used to accelerate large language model servers, including vLLM.

Unauthenticated ZeroMQ messages reach unsafe deserialization

LMCache multiprocess mode runs the cache as a standalone service that LLM workers contact through ZeroMQ. Its registration and cached-data sharing socket does not authenticate clients. One message format is deserialized with Python pickle, which can execute code as it is decoded.

JFrog researcher Yuval Moravchick found that LMCache unpacks the relevant data while processing message arguments, before validating the message type. A crafted network message can therefore trigger code supplied by the sender. The resulting code runs with the privileges assigned to the LMCache process.

That privilege level can be particularly significant in container deployments. JFrog states that LMCache runs as root in the project’s official container images, meaning successful exploitation could execute commands with root permissions in that container.

Exposure depends on the listener address

The multiprocess server listens on the local machine by default, preventing connections from other hosts. The risk changes when an operator starts it on a routable address, a configuration commonly used when cache services are shared among machines in multi-node deployments.

LMCache’s Kubernetes deployment example starts the server on every network interface. By contrast, an LMCache instance running inside a single vLLM process does not open this network port. Administrators therefore need to distinguish standalone multiprocess services from in-process deployments when assessing exposure.

JFrog recommends avoiding routable addresses until a patched release is issued and keeping the port limited to localhost or a trusted cluster network. A firewall can reduce the number of hosts able to connect, but it cannot eliminate the vulnerability: any permitted host can send a message that executes code.

Separate reports and a fixed vLLM denial-of-service bug

Six other LMCache security reports were filed on GitHub on October 6. They claim cross-tenant cached-data access and unauthenticated command-execution services, but they have no CVE, maintainer confirmation, or fix. One report concerns an admin HTTP default that changed: it listened on every interface in 0.5.5 but is local-host-only in 0.5.6 release candidates.

A separate vLLM issue, CVE-2026-105756, was fixed in vLLM 0.30.0 on September 22. A malformed cache_salt request could crash engines using the LMCache multiprocess connector. It is rated 6.5 and is a denial-of-service issue rather than a code-execution flaw.

For businesses running LLM infrastructure, the immediate task is to inventory LMCache multiprocess endpoints, verify their bind addresses and network reachability, and limit the service to local or trusted cluster access while awaiting a vendor fix.