Critical LMCache Vulnerability Enables Unauthenticated Remote Code Execution

A critical security vulnerability in LMCache, an open-source component used for AI inference workloads, could allow an unauthenticated attacker to execute arbitrary code on vulnerable deployments.

Tracked as CVE-2026-105192, the vulnerability has a CVSS score of 9.8, placing it in the critical severity category. JFrog Security Research disclosed the issue on October 7, 2026, identifying unsafe Python pickle deserialization in LMCache's multiprocess, or distributed, ZeroMQ transport.

The issue is particularly relevant to deployments where the LMCache multiprocess transport is configured with a routable network address. A default single-host installation that keeps the transport bound to localhost is not reachable from other machines, according to JFrog.

What Is LMCache?

LMCache is an open-source component designed to support AI and large language model inference workloads by providing a KV cache layer. It can operate in different configurations, including a multiprocess or distributed mode where worker processes communicate to register and share KV cache blocks.

In multiprocess mode, LMCache uses a ZeroMQ ROUTER transport for communication between worker processes.

The security problem arises because the transport does not authenticate incoming connections and a portion of the received data can ultimately reach Python's pickle.loads function.

Python pickle is capable of reconstructing Python objects during deserialization. If untrusted data reaches pickle.loads, specially crafted serialized data can trigger code execution.

That combination of an unauthenticated network transport and unsafe deserialization creates the core security issue behind CVE-2026-105192.

What Makes CVE-2026-105192 Dangerous?

The vulnerability combines several conditions that can make exploitation serious in an exposed deployment.

First, JFrog reports that the ZeroMQ transport used by LMCache's multiprocess mode does not have authentication such as CURVE, ZAP, password protection or message authentication.

Second, incoming messages use MessagePack, but a MessagePack extension is registered for DeviceIPCWrapper. That data is passed to DeviceIPCWrapper.Deserialize, which calls pickle.loads.

The deserialization occurs while LMCache is still decoding the request, before the normal request handler runs.

According to JFrog, this means a single unauthenticated ZeroMQ message can cause code to execute with the privileges of the LMCache process.

The CVE record classifies the issue under:

• CWE-306: Missing Authentication for Critical Function

• CWE-502: Deserialization of Untrusted Data

The assigned CVSS 3.1 score is 9.8 Critical, with the vector indicating network-based exploitation without authentication or user interaction and high impact to confidentiality, integrity and availability.

When Is a Deployment Exposed?

Not every LMCache installation is automatically exposed to remote attackers.

This distinction is important.

JFrog states that the multiprocess transport binds to localhost by default. In that configuration, another machine cannot directly connect to the transport.

The risk changes when an operator configures LMCache with a routable address using the --host option. This is relevant to multi-node deployments where worker processes need to communicate across hosts.

JFrog specifically notes that the 9.8 severity rating applies to the routable configuration.

There is another important distinction: LMCache used only inside a single vLLM process does not open this multiprocess transport port, according to the advisory.

This means security teams should first determine how LMCache is deployed before assessing the actual exposure.

Deployment scenarios

The company did not provide specific information about the security status of individual deployments.

Affected LMCache Versions

JFrog reports that the vulnerable code path was introduced in LMCache 0.3.9.

The research also states that the vulnerable path remained present in version 0.5.5, the latest PyPI release at the time of the advisory, as well as the 0.5.6 release candidates through 0.5.6rc3 and the development branch as of October 7, 2026.

PyPI confirms that version 0.5.5 was released on September 12, 2026, while 0.5.6rc3 was released on October 6, 2026.

Affected range reported by the CVE record

LMCache 0.3.9 and later

The CVE record currently does not identify a fixed version.

No Fixed Release Was Available at Disclosure

One of the most important aspects of this vulnerability is the lack of a published fixed release at the time of JFrog's disclosure.

JFrog states that no fixed version was available as of October 7, 2026. The vulnerable deserialization path remained present in the latest stable release, the 0.5.6 release candidates and the development branch examined by the researchers.

This creates a different response situation from a typical vulnerability where organizations can immediately upgrade to a patched version.

For affected operators, the immediate priority is therefore exposure reduction while monitoring for a vendor fix.

Additional details were not disclosed in the announcement.

How the Vulnerability Works

At a high level, the vulnerable sequence looks like this:

1. A client connects to the ZeroMQ transport

The multiprocess LMCache service accepts connections through its ZeroMQ transport.

2. The connection does not require authentication

JFrog reports that the socket does not use authentication mechanisms such as CURVE, ZAP or message authentication.

3. LMCache receives a MessagePack message

The incoming message contains data used by the LMCache multiprocess protocol.

4. A MessagePack extension reaches DeviceIPCWrapper.Deserialize

The relevant extension is associated with DeviceIPCWrapper.

5. The deserialization routine calls pickle.loads

This is the critical operation. Instead of treating the incoming network data as untrusted content, the data reaches Python's pickle deserialization mechanism.

6. Code can execute before normal request handling

JFrog reports that the pickle operation happens while request arguments are being decoded, before the handler runs.

This is why the issue is classified as remote code execution rather than merely a malformed-input or denial-of-service vulnerability.

Why Pickle Deserialization Is a Security Concern

Python's pickle mechanism is designed for serializing and reconstructing Python objects.

The security concern is that pickle data should not be treated as inherently safe when it comes from an untrusted source. Deserializing maliciously constructed pickle data can invoke functionality during object reconstruction.

That becomes particularly dangerous when the data originates from a network service that does not authenticate its clients.

In CVE-2026-105192, JFrog identified exactly this combination in the LMCache multiprocess transport:

Network-accessible service + no authentication + unsafe pickle deserialization

The CVE record consequently assigns CWE-502, Deserialization of Untrusted Data, alongside CWE-306 for missing authentication.

Potential Impact

Successful exploitation could allow an attacker to execute code with the privileges of the LMCache process.

JFrog reports that official container images run the LMCache process as root. If such an image is used in an exposed vulnerable configuration, code execution could therefore occur with root privileges inside that container.

The broader impact depends on the surrounding deployment.

For example, the consequences of code execution can depend on:

• The privileges assigned to the LMCache process

• Network access available from the workload

• Credentials accessible to the process

• Connectivity to other infrastructure

• Container isolation

• Kubernetes or cloud permissions

• Whether the vulnerable transport is reachable from untrusted systems

The source does not provide specific customer incidents or confirmed compromises.

The company did not provide specific information about this area.

What Organizations Should Do Now

Because there was no fixed release available at the time of disclosure, organizations using LMCache should focus first on reducing exposure.

1. Identify LMCache deployments

Security teams should determine where LMCache is installed and identify the versions in use.

Pay particular attention to deployments using multiprocess or distributed mode.

2. Check the network binding

Determine whether the LMCache transport is bound only to localhost or configured with a routable address.

JFrog specifically recommends avoiding a routable --host configuration until a release containing the security fix is available.

3. Restrict network access

Where multiprocess communication is required, restrict access to trusted systems and networks.

A firewall can reduce the number of systems able to reach the service, although it does not eliminate the underlying vulnerability.

JFrog notes that any host capable of connecting to the transport can potentially execute code as the LMCache process.

4. Monitor for a fixed release

Organizations should monitor the LMCache project and package releases for a version that removes the unsafe deserialization path or introduces appropriate authentication and validation.

The current PyPI release history shows 0.5.5 as the stable release and 0.5.6rc3 as a pre-release as of October 6, 2026.

5. Review process privileges

Where possible, AI infrastructure components should operate with only the permissions they require.

Running vulnerable services with elevated privileges can increase the potential consequences of a successful compromise.

JFrog's advisory specifically highlights root execution in official container images.

6. Review logs and network activity

Security teams should review relevant network and application logs for unexpected connections to the LMCache multiprocess transport.

Organizations with potentially exposed systems should also investigate unusual activity around the affected workloads.

The announcement does not provide a definitive compromise-detection procedure.

What the Fix Needs to Address

JFrog's mitigation guidance points toward two important changes.

The first is removing the use of pickle for network-controlled data. The advisory recommends replacing the serializer behind the relevant MessagePack extension with a safer format and avoiding pickle.loads on data received from unauthenticated peers.

The second is authentication.

JFrog recommends authenticating the ZeroMQ transport, mentioning mechanisms such as CURVE or HMAC-based message authentication. It also recommends preventing a routable binding unless appropriate authentication is configured.

These recommendations address the two core weaknesses represented by the CVE classifications:

CWE-502: Unsafe deserialization

CWE-306: Missing authentication

Until an appropriate fix is available, exposure reduction remains an important defensive measure.

Broader Security Lesson for AI Infrastructure

The LMCache vulnerability highlights a broader industry shift toward securing the infrastructure underneath AI applications, not just the models themselves.

Modern AI systems increasingly depend on supporting components such as inference servers, model gateways, vector databases, caching layers, orchestration platforms and distributed communication services.

A component may not directly expose a user-facing AI model and can still become an important security boundary.

In this case, the issue is not a prompt injection vulnerability or a model behavior problem. It exists in the infrastructure used for distributed AI workloads.

For enterprises, this could mean that AI security programs need to include the full application and infrastructure stack:

Model → Inference Server → Cache → Network Transport → Container → Orchestration → Cloud Infrastructure

The development also reflects growing demand for secure-by-default configurations in distributed AI systems. Network services that assume trusted peers can become high-impact targets when they are accidentally exposed beyond their intended environment.

Conclusion

CVE-2026-105192 demonstrates how a relatively small infrastructure component can create a serious security boundary when distributed communication and unsafe deserialization are combined.

The vulnerability is especially significant for LMCache deployments using multiprocess mode with network-reachable ZeroMQ transport. Organizations should identify affected deployments, verify network bindings, restrict access to trusted systems and monitor the project for a fixed release.

The incident also reinforces a broader lesson for AI infrastructure: security controls need to extend beyond the model and application layer into the caching, networking, serialization and container components that support AI workloads.