Skip to content

Security Independently confirmed2 publishers 2 min read Published Updated

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

Send a correction

Illustration accompanying LMCache's multiprocess cache server runs attacker code from one unauthenticated message
Generated illustration

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.

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
Why these scores

Claim ledger

Ranked by verification strength, evidence, and original report placement.

  1. [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.

    Reported SupportedView cited source
  2. [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.

    Reported SupportedView cited source
  3. [3]

    No fixed or patched version of LMCache exists for CVE-2026-105192.

    Reported SupportedView cited source
  4. [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.

    Reported SupportedView cited source
  5. [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.

    Reported SupportedView cited source
  6. [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.

    Reported SupportedView cited source
  7. [7]

    LMCache's own example Kubernetes deployment starts the multiprocess server listening on every network interface.

    Reported SupportedView cited source
  8. [8]

    A copy of LMCache running inside a single vLLM process does not open the port at all.

    Reported SupportedView cited source
  9. [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.

    Reported SupportedView cited source
  10. [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.

    Reported SupportedView cited source
  11. [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.

    Reported SupportedView cited source
  12. [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.

    Reported SupportedView cited source
  13. [13]

    LMCache has not published a security advisory for the flaw.

    Reported SupportedView cited source
  14. [14]

    The flaw was found by Yuval Moravchick of JFrog's security research team.

    Reported SupportedView cited source
  15. [15]

    JFrog's advisory does not provide operators with a way to determine whether a server has already been attacked.

    Reported SupportedView cited source
  16. [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.

    Reported SupportedView cited source
  17. [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.

    Reported SupportedView cited source
  18. [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.

    Reported SupportedView cited source
  19. [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.

    Reported SupportedView cited source
  20. [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.

    Reported SupportedView cited source

Sources

2 independent publishers whose own reporting we read for this story.

  1. dev.to

    1 article · October 9, 2026

    An Unauthenticated KV Cache Server Puts Code Execution on Your Cluster Network
  2. thehackernews.com

    2 articles · October 8, 2026

    Unpatched Critical LMCache Flaw Lets Unauthenticated Attackers Run Code Remotely

Topics and entities

Topics

  • LLM serving infrastructure
  • AI inference security
  • Insecure Deserialization

Entities