Device IPC deserialization fix merged into the dev branch
On October 7, 2026, JFrog Security Research publicly disclosed a deserialization remote code execution vulnerability in LMCache’s multiprocess (MP) mode (CVE-2026-105192, CVSS 3.1 score 9.8). We received the report on Oct 7th and began working on a fix the same day. The fix (PR #5644) was merged into the dev branch on October 12 and will ship in 0.5.6, expected this week.
This note describes the vulnerability, the fix, how to protect and check your deployments, and the work that remains.
1. The Vulnerability
The issue is in the ZeroMQ transport used in multiprocess (distributed) mode. The transport port (5555 by default) is unauthenticated, and device IPC descriptors are deserialized with pickle.loads during message decoding. A single crafted message lets an attacker execute arbitrary code with the privileges of the LMCache process.
Affected versions: 0.3.9 through 0.5.5, the 0.5.6 release candidates, and development branches before the fix.
Who is exposed: By default the transport binds only to localhost, and single-process / in-process (IP) mode does not open the port. Deployments are exposed when the transport binds a routable address, as multi-node setups do.
- One point raises the risk for many users: our example Kubernetes deployment binds all interfaces. If you based your deployment on it, assume you are exposed. We have updated the example to use localhost by default.
2. The Fix
The fix replaces pickle with versioned, typed MessagePack descriptors. Descriptors are validated first, and the device wrapper type is then selected from a fixed local allowlist. Class names are never taken from network input, and there is no pickle fallback. Both the ZeroMQ and gRPC transport paths are covered, and malformed descriptors are rejected.
We tested the fix against multiple different attack messages, including the one in the original CVE report plus a stress test case that tries to execute customized scripts on the host. All the executed malicious code before the fix was blocked after it. Legitimate requests continued to work normally, and 116 regression tests passed.
Upgrade workers and servers together. The wire format has changed, so mixing old and new versions is not supported.
3. What to Do Now
If you run multiprocess mode, take these steps until 0.5.6 is released:
- Don’t bind the transport to a routable address. Keep it on localhost, or on a trusted cluster network only.
- Firewall the transport port (5555 by default, or whatever you configured) with network policies or host firewall rules.
- Run as a non-root user. The official non-root Docker images will be released with 0.5.6. If you need to use Docker images before 0.5.6’s release, please build a customized one using our provided Dockerfile.
- Review deployments based on our Kubernetes example, which bound all interfaces.
4. Checking for Compromise
If your transport port was reachable from an untrusted network at any point, treat the host as potentially compromised. Exploitation happens before the message is processed, so a rejected or malformed request in your logs does not mean the attack failed.
We suggest:
- Reviewing connections to the transport port from unexpected sources.
- Looking for unexpected child processes, shells or outbound connections from the LMCache process.
- Rotating credentials and secrets reachable from affected containers, and redeploying from clean images.
5. Follow-up Work
This fix covers the device IPC descriptor deserialization path. Two related items remain:
- Authentication for the RPC transport. LMCache currently does not require authentication for RPC between the LMCache server and the MP coordinator or the frontend. We plan to add RPC authentication support in 0.5.7.
- Pickle on the engine-driven path. We also observed pickle usage in the engine-driven path (CPU-data / retrieve-response handling). This path is disabled by default and is not reachable from the network, and we plan to remove the pickle usage before 0.5.8.
6. Acknowledgments
We thank Yuval Moravchick of JFrog Security Research for reporting this issue and for the detailed analysis. We welcome security reports from the community through GitHub Security Advisories.
