LMCache: unauthenticated remote code execution, no fix available
LMCache's multiprocess mode accepts pickled data on an unauthenticated ZeroMQ socket, so one message can run code as root.
· JFrog · Research by Yuval Moravchick (JFrog Security Research Team), yyymk
CVE-2026-105192 lets anyone who can reach LMCache's multiprocess transport port run code as the LMCache user, with no credentials and no fixed release. Official container images run that process as root.
01What happened
JFrog Security Research disclosed CVE-2026-105192 on 7 October 2026, an unauthenticated remote code execution flaw in LMCache, the distributed KV cache used to speed up LLM serving alongside vLLM. Yuval Moravchick of JFrog found it, and the advisory carries a CVSS score of 9.8. A second unauthenticated code execution path in LMCache's internal API server, CVE-2026-107204, was reported in the project's issue tracker a day earlier.
02How it works
Multiprocess mode opens a ZeroMQ ROUTER socket with no authentication: no CURVE, no ZAP, no password and no message authentication. Incoming msgpack messages carrying extension code 1 are handed to DeviceIPCWrapper.Deserialize, which calls pickle.loads while decoding the arguments for REGISTER_KV_CACHE. Deserialization happens before the request handler runs, so a single crafted message executes code as the LMCache process user.
03Who is affected
LMCache 0.3.9 and later are affected in multiprocess mode, which the project also calls distributed mode. Exposure depends on the bind address: the transport listens on localhost by default, and JFrog's 9.8 score applies to deployments that set a routable address with --host, as multi-node clusters commonly do. LMCache running only inside a vLLM process does not open the port.
04What to do
Keep the LMCache transport port, 5555 by default, on localhost or a trusted cluster network, and do not set --host to a routable address until a release ships a fix. JFrog notes that a firewall reduces who can reach the port but does not remove the risk from any host that can still connect.
Questions people ask
- Is my LMCache deployment exposed to CVE-2026-105192?
- LMCache is exposed when multiprocess mode binds a routable address through --host, which multi-node deployments commonly do. JFrog states that a stock single-host install keeps the transport on localhost and is not reachable from other machines, and that LMCache used only inside a vLLM process never opens the port. Check whether port 5555 answers from another host.
- Is there a patch for LMCache?
- No fixed release existed when JFrog published the advisory on 7 October 2026. JFrog reports that the latest PyPI release v0.5.5, the v0.5.6 release candidates and the dev branch all still call pickle.loads on data from unauthenticated peers. JFrog's advice until a fix ships is direct: do not set --host to a routable address.
- What can an attacker do with CVE-2026-105192?
- An attacker who can reach the ZeroMQ transport port needs no credentials and can run code as the user running LMCache. JFrog notes that the official container images run that process as root. One crafted message is decoded with pickle.loads during argument handling, before any request handler runs, so no valid session is needed.
- How does CVE-2026-107204 differ from the ZeroMQ flaw?
- CVE-2026-107204 is a separate unauthenticated remote code execution path, in LMCache's internal API server rather than the ZeroMQ transport. Callers post Python to the /run_script endpoint, then reach the real builtins through the exposed FastAPI app object to escape the sandbox and run operating system commands. The GitHub user yyymk reported it on 6 October 2026.
Sources 4 links, all fetched
- 1research.jfrog.comJFrog Advisory
- 2github.comGitHub Advisory
- 3github.comSecond RCE Advisory
- 4github.comLMCache Issue 5510