JFrog Discloses Unpatched Critical LMCache Flaw, CVE-2026-105192, With No Fixed Version Available

JFrog disclosed a critical flaw, tracked as CVE-2026-105192, in LMCache, open-source software that accelerates LLM servers such as vLLM. According to JFrog, an unauthenticated attacker can run code on the cache server. The advisory is dated Oct. 7, 2026, and no fixed version exists.

JFrog rates the flaw 9.8 out of 10, which is critical. That score applies to the configuration where the server is bound to a routable address, per JFrog’s advisory. Default single-host installs are not remotely reachable.

Affected versions and scope

Affected versions run from 0.3.9, released in October 2025, through 0.5.5, the latest PyPI release, according to JFrog and the outlets covering its advisory. The 0.5.6 release candidates through 0.5.6rc3 and the dev branch as of Oct. 7, 2026 are also affected. No fixed version exists.

The vulnerable component is LMCache’s multiprocess, or distributed, mode. In that mode a standalone server talks to workers over a ZeroMQ ROUTER socket. JFrog says the socket has no authentication: no CURVE, ZAP, password or message authentication. The default port is 5555.

JFrog researcher Yuval Moravchick found the flaw, and JFrog tracks it as JFSA-2026-001694382.

How the bug works

The root cause is unsafe deserialization, which means turning incoming bytes back into program objects without checking them. Python’s pickle format can run code while decoding, so it is unsafe for untrusted input. JFrog says a msgpack extension (code 1) is passed to DeviceIPCWrapper.Deserialize, which calls pickle.loads on network data.

That call happens while the server is still decoding request arguments. It runs before any handler or message-type check. As a result, JFrog says, a single crafted message can execute code.

Injected code runs with the privileges of the LMCache process. JFrog says the project’s official container images run that process as root. That makes the container the first thing an attacker would control, according to the advisory’s description.

Who is exposed

By default, the transport binds to localhost and is not reachable from other machines, per JFrog. It becomes remotely exposed only when an operator sets a routable address with the –host option, as multi-node deployments do. LMCache used inside a single vLLM process does not open the port.

The Hacker News reports that LMCache’s own example Kubernetes deployment starts the server listening on every network interface. Teams that copied that example into a cluster would therefore have the routable configuration the 9.8 score assumes.

Byteiota reports that LMCache runs in production stacks including Google Cloud GKE Inference, CoreWeave, NVIDIA Dynamo and IBM’s LLM serving stack. It also says the vLLM production-stack deployment guides recommend setting –host to a routable address. Only Byteiota makes those claims among the sources reviewed, and the article does not show which deployments are actually exposed.

Why this is a supply-side problem

LMCache sits in the LLM serving path. An unauthenticated, root-capable code execution bug there can compromise inference infrastructure, which is the practical consequence of the flaw. Operators who never wrote a line of the vulnerable code inherit the risk by pulling a dependency.

The bug class is not new to AI tooling. The Hacker News notes that the ShadowMQ set of November 2025 disclosures hit other inference projects with the same error: handing unauthenticated socket input to pickle. The outlet adds that no one has established whether LMCache’s code shares a source with those projects.

Related LMCache exposure has appeared in vLLM itself. The Hacker News reports a vLLM denial-of-service flaw, CVE-2026-105756, rated 6.5, affected deployments using the LMCache multiprocess connector. It does not allow code execution and was fixed in vLLM 0.30.0, released Sept. 22.

What JFrog recommends while no patch exists

JFrog’s interim guidance is not to assign the multiprocess server a routable address. It says to keep the port on localhost or a trusted cluster network.

JFrog also cautions that a firewall reduces exposure but does not remove it. Any host that can connect to the port can still run code. A compromised neighbor inside a cluster is therefore enough, based on that description.

For a permanent fix, JFrog recommends three changes to the project:

• Replace the pickle-based serializer with a safe format.
• Authenticate the ZMQ transport, using CURVE or per-message HMAC.
• Refuse routable binding unless authentication is configured.

Open questions

The reports do not agree on whether a public proof-of-concept exists. Cyber Security News reports a PoC was released, and Byteiota says one was published on GitHub the day of disclosure. TheHackerWire’s coverage and another report say none was public on Oct. 7.

JFrog’s advisory itself contains exploit steps.

The Hacker News and Byteiota report that LMCache had not published a security advisory as of their reporting. Byteiota adds that JFrog’s advisory gives operators no way to tell whether a server was already attacked. Neither source cites a vendor, agency or researcher saying the flaw is exploited in the wild.

The two outlets also report that a GitHub user filed six more LMCache security reports on Oct. 6. They allege cross-tenant cache access and command-executing network services without login. According to those reports, the filings rest on proof-of-concept claims and have no CVE, maintainer confirmation or fix.

Patch and mitigation status

Patch status: none. Every release from 0.3.9 through 0.5.5 is affected, as are 0.5.6rc3 and the dev branch as of Oct. 7, 2026, according to JFrog.

Mitigation status: JFrog’s only interim measure is network placement, keeping the multiprocess server on localhost or a trusted cluster network instead of a routable address. The vendor-side fixes JFrog describes, a safe serializer and an authenticated transport, have not shipped.