Critical LMCache flaw leaves routable distributed caches open to remote code execution

LMCache operators using its multiprocess architecture need to check where the cache transport is listening. JFrog Security Research disclosed CVE-2026-105192 on October 7, rating the issue Critical at CVSS 9.8 and reporting that no fixed release was available at publication time.

What is exposed

The vulnerable path is specific, but serious. According to JFrog, LMCache’s multiprocess — also called distributed — mode opens a ZeroMQ ROUTER socket so workers can register and exchange KV-cache blocks. That socket has no message authentication. During registration, a msgpack extension reaches Python’s pickle.loads, allowing a client that can connect to the transport to run code as the LMCache process user before the server handles the request.

JFrog says the affected decode path first shipped in LMCache 0.3.9 and remained present in the latest PyPI release, 0.5.5, the 0.5.6 release candidates through rc3, and the development branch as of October 7. The researchers also found that official container images run the affected process as root, increasing the impact of successful exploitation.

The default configuration narrows the exposure. JFrog says the transport binds to localhost unless an operator sets --host to a routable address for multi-node use; LMCache running only inside a vLLM process does not open the affected port. The 9.8 score applies to the routable configuration, not a stock single-host deployment left on loopback.

Why inference teams should care

LMCache describes itself as a vendor-neutral KV-cache layer for LLM inference, with persistent cache reuse across serving engines and support for distributed cache transfer and storage backends. Its project materials specifically document multiprocess production deployment and integrations across the inference ecosystem. That makes network placement and process identity part of the security boundary, rather than a deployment detail.

For teams pairing LMCache with vLLM or other serving engines, the immediate question is whether port 5555 — the documented default in JFrog’s reproduction — is reachable from outside the intended cache-worker network. Any reachable peer can attempt the unauthenticated decode path; a firewall limits who can connect but does not authenticate peers already on that network.

What to do now

JFrog’s interim guidance is to avoid binding the multiprocess transport to a routable address, keep it on localhost or a trusted cluster network, and restrict the port with firewall policy. Because no fixed version was available when the advisory was published, upgrading alone is not yet a mitigation.

Longer term, JFrog recommends replacing pickle for network-supplied data and authenticating the ZeroMQ transport, for example with CURVE or per-message authentication. Operators should watch the LMCache project for a release that removes the unsafe deserialization path, then validate that their deployed images actually contain that change before reopening broader network access.