Security1 publisherNot yet confirmed elsewhere2 min readPublished
LMCache's multiprocess cache server runs attacker code from one unauthenticated message
JFrog disclosed CVE-2026-105192 on October 7, an unauthenticated code-execution flaw rated 9.8 in LMCache's multiprocess server that has no fixed version. Other machines cannot reach a server left on the localhost default, but caches shared across nodes are bound to routable addresses.
The Watch · Security desk
What happened
- Every LMCache release from 0.3.9, shipped in October 2025, through current stable 0.5.5 is affected, as are the 0.5.6 release candidates and the development branch.
- LMCache running inside a single vLLM process does not open the vulnerable port; only the standalone multiprocess server does.
- Injected code runs with the LMCache process's privileges, and JFrog says that process runs as root on the project's official container images.
- LMCache's maintainers have not published their own security advisory for the flaw.
- One GitHub user filed six more LMCache security reports on October 6, alleging cross-tenant cache access and network services that run commands without a login.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- exposure Clusters deployed from LMCache's example Kubernetes manifest run the reachable configuration, so every host that can route to the server's port can execute code on it.
- constraint Caches shared across nodes cannot move back to localhost, so until a release ships every host on the cluster network is effectively trusted with code execution on the cache server.
- decision Operators who exposed a multiprocess server at any point since 0.3.9 have to decide without vendor guidance whether to rebuild those hosts as possibly compromised.
- precedent A second appearance of the ShadowMQ error means unauthenticated ZeroMQ endpoints in inference stacks should be checked for pickle decoding as a matter of course.
The attack takes one connection and one message. Worker processes use a ZeroMQ socket on the multiprocess server to register and share cached data, and anyone can connect to it without credentials [9]. One message type carries a pickle payload. The server decodes that payload while it is still reading the message's arguments, before it checks what type of message has arrived [9]. Pickle can carry code that runs during decoding, so a single crafted message executes commands before the server does any validation [4][9].
JFrog's 9.8 is the score it gives a server bound to a routable address [2]. Against a server on the localhost default, an attacker would first need a foothold on that machine [6]. The project's own reference setup is the exposed one: LMCache's example Kubernetes deployment starts the server listening on every network interface [7].
No fixed version exists [3]. Until one does, JFrog's advice is to keep the port on the local machine or a trusted cluster network and not to give the server a routable address [12]. JFrog says a firewall on the port lowers the risk without removing it, because any host that can still open a connection can run code [13]. JFrog's advisory does not include a way to tell whether a server has already been attacked [15].
Yuval Moravchick of JFrog's security research team found the confirmed flaw [11]. The six reports filed the day before have a different status. They come from one account and rest on proof-of-concept claims. None has a CVE, confirmation from the maintainers or a fix [17]. One of them concerns a default that has since changed. LMCache's admin HTTP server listened on every network interface in 0.5.5. In the 0.5.6 release candidates it listens only on localhost [18].
The only available vLLM upgrade fixes a different bug [3][19]. vLLM 0.30.0, released September 22, fixed CVE-2026-105756. Before that release, sending one request with a malformed cache_salt was enough to crash the engine in deployments running LMCache's multiprocess connector [19]. That bug is rated 6.5. It causes denial of service and does not allow code execution [19].
The core error is passing data from an unauthenticated socket to pickle. Researchers found the same error across other AI inference frameworks in November 2025 and called the group of flaws ShadowMQ [20]. Nobody has established whether LMCache's code shares a common source with those projects [20].
What to watch
- An LMCache release or advisory for CVE-2026-105192, and whether the fix adds authentication to the ZeroMQ socket or removes pickle decoding.
- Maintainer response to the six October 6 reports; a confirmation or CVE would extend exposure beyond the multiprocess server.
- A change to LMCache's example Kubernetes deployment so it stops binding the server to every network interface.