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.
Why it matters
- Who's exposed 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.
- What it limits 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.
- Who has to decide 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.
- What it sets up 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.
Next story · Build · 6h ago
Reflection's 501B-parameter Beam coding model launches on SageMaker JumpStartConfirmed2 publishers
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 [11]. 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 [12]. 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 [14]. 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.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence72
- Adoption
- Not scored
- Hype gap+10
- Incentives
- Not scored
- Confidence68
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
JFrog disclosed a vulnerability in LMCache, open-source software that speeds up LLM servers such as vLLM, on October 7; it is tracked as CVE-2026-105192 and lets an attacker run code on the cache server without logging in.
- [2]
JFrog assigned the flaw a severity score of 9.8 out of 10, the rating it gives a server bound to a routable address.
- [3]
No fixed or patched version of LMCache exists for CVE-2026-105192.
- [4]
The flaw is in LMCache's multiprocess mode, where the cache runs as a standalone server that LLM workers reach over the ZeroMQ messaging library; a single network message to that server can run commands as the user the LMCache process runs as.
- [5]
CVE-2026-105192 affects LMCache from version 0.3.9, released in October 2025, through 0.5.5, the latest stable release, and is also present in the 0.5.6 release candidates and the development branch.
- [6]
By default the multiprocess server listens only on the local machine, so another host cannot reach it; it becomes reachable when an operator starts it with a routable address, much like multi-node deployments share a cache across machines.
- [7]
LMCache's own example Kubernetes deployment starts the multiprocess server listening on every network interface.
- [8]
A copy of LMCache running inside a single vLLM process does not open the port at all.
- [9]
The ZeroMQ socket the multiprocess server opens for worker processes to register and share cached data has no authentication; one message type is unpacked with pickle, which can carry code and run it as data is decoded, and the server unpacks it while reading the message's arguments, before any check of the message's type.
- [10]
The injected code runs with the privileges of the LMCache process; on the project's official container images that process runs as root, according to JFrog.
- [11]
Until a patched release ships, JFrog advises operators not to assign the multiprocess server a routable address and to keep its port on the local machine or on a trusted cluster network.
- [12]
A firewall that limits who can reach the port lowers the risk but does not remove it, because any host that can still open a connection can run code.
- [13]
LMCache has not published a security advisory for the flaw.
- [14]
The flaw was found by Yuval Moravchick of JFrog's security research team.
- [15]
JFrog's advisory does not provide operators with a way to determine whether a server has already been attacked.
- [16]
A GitHub user opened six additional LMCache security reports on October 6, the day before CVE-2026-105192 was made public, alleging unauthenticated access to cached data belonging to different tenants and to several network services that execute commands without a login.
- [17]
The six reports come from one account, rest on proof-of-concept claims, and have no CVE, no confirmation from the maintainers, and no fix.
- [18]
An LMCache admin HTTP server that listened on every network interface in 0.5.5 listens only on the local host in the 0.5.6 release candidates.
- [19]
Before vLLM 0.30.0, released September 22, a single request carrying a malformed cache_salt value could crash the engine on deployments using the LMCache multiprocess connector; the denial-of-service bug is tracked as CVE-2026-105756, rated 6.5, and does not allow code execution.
- [20]
Handing data from an unauthenticated network socket to pickle is the same mistake researchers found across other AI inference frameworks in November 2025 in a group of flaws called ShadowMQ; whether LMCache's code shares a common source with those projects has not been established.
Sources
2 independent publishers whose own reporting we read for this story.
- dev.toAn Unauthenticated KV Cache Server Puts Code Execution on Your Cluster Network
1 article · October 9, 2026
- thehackernews.comUnpatched Critical LMCache Flaw Lets Unauthenticated Attackers Run Code Remotely
2 articles · October 8, 2026
Topics and entities
Topics
- LLM serving infrastructure
- AI inference security
- Insecure Deserialization