JFrog Discloses Critical LMCache Flaw Allowing Remote Code Execution, With No Fixed Release Available

JFrog's security research team published a critical vulnerability in LMCache on October 7. LMCache is open-source software that speeds up large language model servers such as vLLM by caching data and handing it back to workers on later requests.

The flaw, tracked as CVE-2026-105192, carries a severity score of 9.8 out of 10. It lets an attacker run commands on the cache server without logging in. No fixed version exists.

JFrog researcher Yuval Moravchick found it.

How the first flaw works

The problem sits in LMCache's multiprocess mode. In that mode the cache runs as a standalone server, and LLM worker processes reach it over ZeroMQ sockets.

That socket has no authentication. One message type is decoded with pickle, Python's serialization format, which can carry executable code. The server unpacks the message while it reads its arguments, before it checks what type of message it is. A crafted message therefore runs the sender's code.

The code runs with the privileges of the LMCache process. According to JFrog, that process runs as root on the project's official container images.

The affected range starts at version 0.3.9, released in October 2025, and runs through 0.5.5, the latest stable release. The 0.5.6 release candidates and the development branch are also affected.

Who is actually exposed

The 9.8 score applies to a server reachable over the network. By default, the multiprocess server listens only on the local machine, so other hosts cannot connect.

It becomes reachable when an operator binds it to a routable address, which is common in multi-node setups that share a cache across machines. LMCache's own example Kubernetes deployment starts the server listening on every network interface.

A copy of LMCache running inside a single vLLM process does not open the port at all.

JFrog's advice: do not give the multiprocess server a routable address. Keep the port on localhost or on a cluster network that only trusted hosts can join.

A firewall helps but does not close the hole. Any host that can still open a connection can run code.

A second CVE, a different bug

A separate entry, CVE-2026-107204, was also published October 7. It is a different flaw from JFrog's.

The CVE record says LMCache through 0.5.5 accepts unauthenticated POST requests to a /run_script endpoint and executes the submitted Python. According to the record, an attacker can use the exposed FastAPI application object to recover the real Python builtins, get around the guarded __import__, import the os module and run operating system commands as the LMCache process.

It is rated 9.8 under CVSS 3.1 and 9.3 under CVSS 4.0, and is classified as missing authentication (CWE-306). The National Vulnerability Database analysis is still pending. The record's references include LMCache issue #5510 and a VulnCheck advisory.

This is not the pickle problem. It is a straight HTTP endpoint that runs submitted scripts. One security vendor tracking it said no public exploit had been published in open research repositories as of its writing.

The records reviewed do not say whether the /run_script endpoint is reachable by default or only under certain configurations. That question matters for who needs to act, and it is unanswered.

Six more reports, none confirmed

On October 6, the day before JFrog's disclosure, a single GitHub account filed six additional LMCache security reports. They allege unauthenticated access to cached data belonging to different tenants, and network services that execute commands without a login.

Those are allegations. They come from one account and rest on proof-of-concept claims. They carry no CVE identifier and no confirmation from LMCache maintainers.

For multi-tenant deployments, tenant data leakage would be a separate and serious problem if the claims hold up. Nothing on the record shows they do or do not.

What LMCache has and has not said

LMCache has not published a security advisory for CVE-2026-105192, and its repository carries none. No maintainer response to either CVE or the six reports appears in the record.

JFrog's advisory also gives operators no method to determine whether a server has already been attacked. Anyone who ran the multiprocess server on a routable address, especially from the example Kubernetes manifest, is working blind.

The practical picture is narrow but ugly. Default installs are not remotely reachable through the pickle flaw. Deployments that follow the project's own multi-node example are, and the process behind them can be root.

The open question is when a patched release ships. Until it does, JFrog's guidance to keep the port off routable addresses is the only fix on the table, and LMCache has not yet said whether or when a fixed version is coming.