LMCache Multi‑Process Mode Exposes Unauthenticated Remote Code Execution Vulnerability Impacting Large Model Inference Cache Layer

On October 8, 2026, iThome and JFrog Security Research simultaneously reported that LMCache, when operated in a multi‑process (distributed) configuration, contains an unauthenticated remote code execution vulnerability identified as CVE‑2026‑105192. The vulnerability carries a CVSS v3.1 base score of 9.8, placing it in the critical severity tier, and it enables an attacker to execute arbitrary code on the affected system without any prior authentication or credential requirements.

Vulnerability Overview

The flaw was publicly disclosed by the JFrog research team under the internal reference JFSA‑2026‑001694382 on October 7, 2026. It affects every LMCache release starting with version 0.3.9 and continues through the latest stable release 0.5.5, the testing release 0.5.6rc3, as well as the current development branch, none of which contain a fix at the time of disclosure. The root cause lies in LMCache's use of a ZeroMQ ROUTER socket for cross‑process key‑value cache sharing; the socket listens on TCP port 5555 by default and does not enforce any authentication mechanism such as CURVE, ZAP, password protection, or HMAC.

Technical Details

In a multi‑node deployment scenario, operators are required to supply a routable address via the `--host` command‑line argument. Supplying this argument causes the ZeroMQ socket to transition from being bound exclusively to localhost to being reachable from external hosts. LMCache employs msgpack as its wire‑format encoder, and msgpack's extension code 1 is mapped to the function `DeviceIPCWrapper.Deserialize`. Inside that function, the Python standard library routine `pickle.loads` is invoked directly on the received data. Because this deserialization occurs while the server is still processing the `REGISTER_KV_CACHE` parameters—well before any request handler is entered—an attacker can inject a malicious pickle payload that is executed immediately, allowing arbitrary Python code execution.

Attack Flow

An adversary needs only to send a specially crafted msgpack message to the exposed TCP port 5555. The embedded pickle payload can be designed to write a file, for example `/tmp/zmq_pwn`, and subsequently trigger a type‑error log entry, thereby proving that the code has been executed within the LMCache process context. The official container image launches LMCache as the root user by default; consequently, a successful exploitation grants the attacker root privileges inside the container, which can then be leveraged to compromise additional services running on the same host.

Affected Scope

The vulnerable versions include the 0.3.9 release, all 0.4.x series, and the entire 0.5.x series, and the official container images distributed by the vendor remain unpatched. iThome also notes that the ZeroMQ port is opened only when LMCache runs as a standalone multi‑process service; if LMCache is embedded solely within a vLLM process, the port is not started and the vulnerability is not exposed. By default, the ZeroMQ socket binds only to localhost, preventing direct remote access unless an administrator explicitly sets the `--host` flag to a routable address, thereby exposing the service to external networks.

Mitigation and Recommendations

JFrog advises operators to immediately restrict the binding address of multi‑process services to localhost and to block TCP port 5555 using host‑based firewalls or cluster‑network policies. Until a secure patch is available, the `--host` parameter should never be set to an IP address that can be routed from outside the trusted network. In the longer term, the transport layer should be redesigned to avoid using pickle for deserialization of untrusted network data; a safer serialization format should be adopted, and authentication such as CURVE or HMAC should be added to the ZeroMQ socket to enforce identity verification.

Follow‑up and Outlook

As of October 8, 2026, the vendor has not released any patched version or updated container image that disables the unsafe deserialization path, and a remediation timeline remains undefined. It is also unclear whether third‑party distributions have back‑ported mitigation measures. Environments that have retained the default localhost binding or that isolate the container from untrusted networks are not directly exposed to remote attackers; however, insider threats or compromised hosts within the same network could still exploit the flaw to obtain the highest privileges inside the container.