CVE-2026-105192, disclosed October 7, lets an unauthenticated attacker send a single network message that can execute arbitrary code on an LMCache multiprocess cache server, and there is no patched release available.
How the multiprocess server can become reachable
LMCache’s multiprocess mode runs a standalone cache server that LLM worker processes contact over ZeroMQ. By default that server listens only on the local machine; it becomes reachable from other hosts when an operator explicitly starts it bound to a routable address. The project’s own example Kubernetes deployment does exactly that — the multiprocess server is configured to listen on every network interface — while a copy of LMCache embedded inside a single vLLM process does not open the port at all.
The technical flaw: unauthenticated ZeroMQ + pickle
The ZeroMQ socket the multiprocess server opens for worker registration and cache sharing carries no authentication. One message type is unpacked with Python’s pickle format, which can contain executable code that runs when data is deserialized. LMCache unpacks that pickle payload while it is still reading the message’s arguments and before checking the message type, so a crafted message can cause arbitrary code execution in the context of the LMCache process.
Because the code runs with the privileges of the LMCache process, the level of impact depends on how that process is run. JFrog notes the project’s official container images run the LMCache process as root.
This site is the portfolio.
OSINTSights runs on Cloudflare Workers, D1, R2, and Vectorize, with an AI pipeline on Hetzner ARM. Nubivance designed, built, and operates it. We do the same for clients.
See what we buildScope, severity, and the missing patch
JFrog disclosed the flaw and assigned it a severity score of 9.8 out of 10 — in the critical range — for a server bound to a routable address. The vulnerability, tracked as CVE-2026-105192, affects LMCache releases from 0.3.9 (October 2025) through 0.5.5 (the latest stable release at time of disclosure). It is also present in 0.5.6 release candidates and in the development branch. At publication no fixed LMCache version exists and the project has not published its own security advisory for the flaw.
JFrog’s mitigation guidance and detection limits
Until a patched release ships, JFrog advises operators not to assign the multiprocess server a routable address: keep the service listening on the local machine or restricted to a trusted cluster network. JFrog also says a network firewall that limits which hosts can reach the port lowers the risk but does not remove it — any host able to open a connection can send a message that runs code. JFrog’s advisory does not provide operators a way to determine whether a server has already been attacked.
Related reports, the vLLM denial-of-service fix, and prior patterns
On October 6 — the day before CVE-2026-105192 was made public — a GitHub user opened six additional LMCache security reports alleging unauthenticated access to cached data belonging to different tenants and to several network services that execute commands without a login. Those reports come from a single account, are supported by proof‑of‑concept claims, have no CVE identifiers, lack confirmation from LMCache maintainers, and have no fix. One of those reports pointed to an admin HTTP server default; LMCache’s default for that component changed between 0.5.5 and the 0.5.6 release candidates (from listening on every interface to listening only on localhost).
Separately, a related but different flaw in vLLM was fixed in vLLM v0.30.0, released September 22. That bug (CVE-2026-105756) could crash the engine on deployments that use the LMCache multiprocess connector by sending a malformed cache_salt value; it was rated 6.5 and did not allow code execution. Researchers have previously pointed to a recurring root mistake — passing unauthenticated network data directly to pickle — in other AI inference frameworks in November 2025, in a set of flaws dubbed ShadowMQ. Whether LMCache’s code shares common origins with those projects has not been established.
What this means for security teams, vLLM operators, and maintainers
- Security teams and infra engineers should audit deployments to confirm multiprocess servers are not bound to routable addresses, review firewall rules that control the ZeroMQ port, and prioritize replacing or hardening container images that run LMCache as root.
- vLLM and multi-node deployment operators should treat LMCache’s multiprocess connector as a network-exposed service only when intentionally configured and assume any reachable host can send messages capable of executing code.
- LMCache maintainers and packagers face pressure to ship a fixed release and to publish a formal advisory; until that happens, operators must rely on configuration changes and network controls rather than a software update.
The record released so far leaves a direct operational choice in the hands of operators: either block network access to the LMCache multiprocess port or accept that any host able to open a connection could execute code with the cache process’s privileges. The practical fix — a patched LMCache release and a public advisory describing detection and remediation — has not yet appeared, and the community will be watching for that next step.
