Critical LMCache Flaw Allows Unauthenticated Remote Code Execution

Critical Vulnerability Discovered in LMCache

JFrog has disclosed a critical vulnerability in LMCache, an open-source software designed to accelerate large language model (LLM) servers like vLLM. The flaw, identified as CVE-2026-105192, allows unauthenticated attackers to execute arbitrary code on the cache server. JFrog assigned the vulnerability a severity score of 9.8 out of 10, categorizing it as critical.

Technical Details of the Exploit

The vulnerability resides in LMCache's multiprocess mode, where the cache operates as a standalone server communicating with LLM workers via the ZeroMQ messaging library. The issue stems from the server's use of Python's pickle format for unpacking messages without authentication. A specially crafted network message containing malicious code can be sent to the server, which then executes the code with the privileges of the LMCache process, potentially as root on official container images.

This exploit is possible because the server unpacks the message's arguments, including the pickle-encoded data, before performing any checks on the message's type or authenticity.

Affected Versions and Exposure Conditions

The vulnerability impacts LMCache versions from 0.3.9 (released October 2025) through the latest stable release, 0.5.5, and is also present in 0.5.6 release candidates and the development branch. Currently, no fixed version is available.

Exposure to this flaw occurs when the LMCache multiprocess server is configured to listen on a routable network address, rather than its default localhost setting. While the default configuration is safe, deployments like LMCache's example Kubernetes setup explicitly configure the server to listen on all network interfaces, making it vulnerable.

Mitigation and Recommendations

As there is no patch, JFrog advises LMCache operators not to assign a routable address to the multiprocess server. Instead, they should keep its port restricted to the local machine or a trusted cluster network. Implementing a firewall to limit access to the port can reduce risk but does not eliminate it, as any host capable of establishing a connection could still exploit the vulnerability.