Critical LMCache Flaw (CVE-2024-XXXX) Gets PoC, Enables RCE

Key Takeaways

• A critical vulnerability (CVE-2026-105192) in LMCache allows unauthenticated remote code execution.
• The flaw affects LMCache versions 0.3.9 and later, particularly in distributed (multiprocess) deployments configured for routable network access.
• A proof-of-concept (PoC) exploit has been released, demonstrating how a malicious ZeroMQ message can trigger arbitrary code execution.
• The vulnerability stems from insecure deserialization of Python pickle data over an unauthenticated ZeroMQ transport.
• As of October 7, no official patch has been released for LMCache.

Critical LMCache Flaw Exposes AI Inference Systems to Remote Code Execution

A severe security vulnerability in LMCache, designated CVE-2026-105192, has been publicly disclosed, along with a functional proof-of-concept (PoC) exploit. This flaw enables unauthenticated remote code execution (RCE) on systems utilizing LMCache in a distributed configuration, posing a significant risk to artificial intelligence (AI) and machine learning (ML) inference environments.

The vulnerability carries a critical CVSS score of 9.8, indicating its high severity. It impacts LMCache versions starting from 0.3.9 and continues to be present in the latest PyPI release, version 0.5.5, as well as release candidates for 0.5.6. As of October 7, the vendor had not released a patched version to address this issue.

Deep Dive into the LMCache Vulnerability

Discovered by Yuval Moravchick of the JFrog Security Research Team, the root cause of CVE-2026-105192 lies within LMCache’s multiprocess mode, also known as distributed mode. In this setup, LMCache leverages a ZeroMQ (ZMQ) service to enable multiple worker processes to register and share cached key-value blocks, a common practice for enhancing the performance of large language model inference systems.

The critical flaw emerges when administrators configure this ZMQ service to listen on a routable network address (e.g., 0.0.0.0) for multi-node operations. JFrog’s analysis revealed that the multiprocess ZMQ transport in LMCache lacks any form of authentication. It neither employs ZeroMQ CURVE security, ZAP authentication, passwords, nor message-level verification, leaving the exposed port vulnerable to any entity capable of reaching it on the network.

The vulnerability is exacerbated by LMCache’s handling of MessagePack (msgpack) data transmitted over the ZMQ connection. Specifically, the DeviceIPCWrapper.Deserialize function processes custom MessagePack extensions. During this process, the function invokes Python’s pickle.loads, a function known to be unsafe when deserializing data from untrusted sources. Malicious pickle data can embed instructions that execute arbitrary code during the deserialization process.

An attacker can exploit this by sending a specially crafted ZMQ message containing a malicious pickle object. LMCache processes this object before any validation or proper handling occurs, leading to the execution of the attacker’s code under the privileges of the LMCache process. In official LMCache container images, this process often runs as root, potentially granting an attacker complete control over the compromised container.

Proof-of-Concept and Exploitation Details

The PoC released by JFrog demonstrates that a single unauthenticated ZeroMQ DEALER message sent to the default service port, 5555, is sufficient to trigger code execution. The exploit typically writes command output to a local file to confirm successful execution, illustrating the ease with which this vulnerability can be leveraged.

The risk is particularly acute in multi-node deployments where LMCache is initiated with the --host option configured to a routable address like 0.0.0.0. This configuration makes the ZMQ transport accessible from remote systems. Conversely, a standard single-host setup where the listener is bound to localhost is not inherently exposed to external machines.

JFrog’s advisory highlights that the unsafe deserialization path was introduced in LMCache version 0.3.9 and persists through current development branches. This vulnerability underscores a recurring security concern in AI and ML environments: the exposure of internal services that rely on Python’s pickle for network data handling without adequate security measures. Previous reports, including those concerning Meta’s Llama Stack, have also detailed similar pickle-based RCE risks facilitated by insecure ZeroMQ communications.

What You Should Do

• Avoid Public Exposure: Immediately ensure that LMCache’s multiprocess service is not exposed to public networks.
• Bind to Localhost: Whenever feasible, configure the LMCache listener to bind exclusively to localhost (127.0.0.1) to prevent remote access.
• Network Segmentation and Firewalls: Implement robust network segmentation and firewall rules to restrict access to the LMCache ZMQ port (default 5555) to only trusted internal networks or specific, authorized hosts.
• Principle of Least Privilege: Run LMCache services with the lowest possible privileges. If running in containers, ensure the process does not operate as root.
• Monitor for Updates: Regularly check for official LMCache releases that address CVE-2026-105192.
• Review Deserialization Practices: As a long-term solution, JFrog recommended that developers remove pickle.loads from any unauthenticated network data handling paths. Instead, replace the serializer in the MessagePack extension with a secure data format and implement strong transport authentication, such as ZeroMQ CURVE or a message authentication code. LMCache should also enforce explicit authentication before allowing binding to routable network addresses.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.