LMCache CVE-2026-105192: Unauthenticated RCE, Fix in 0.5.6

LMCache is a Python package used by LLM serving stacks to share KV cache blocks between processes. A critical flaw in its multiprocess (distributed) mode, tracked as CVE-2026-105192, lets anyone who can reach the transport port send one message and run code as the account that runs LMCache. Version 0.5.6 fixes it.

If you run LMCache across several nodes, deployed from the project's example Kubernetes manifests, or use its official container images, check your exposure now. According to the GitHub advisory, LMCache used only inside a vLLM process does not open the vulnerable port.

What happened

In multiprocess mode, LMCache starts a ZeroMQ ROUTER socket so that sibling worker processes can register and share KV cache blocks. The advisory states that this socket has no CURVE, ZAP, password or message authentication. Only other LMCache processes are meant to connect, yet nothing enforces that.

Messages on the socket use msgpack. One extension type is handed to a function that calls Python's pickle.loads, and this runs while the server is still decoding the arguments of a request, ahead of any handler. A single unauthenticated message to the transport port (5555 by default) is therefore enough to execute code with the privileges of the LMCache process. The advisory adds that official container images ran that process as root.

Why unpickling network data is so risky

Pickle is a Python serialization format whose data can instruct the interpreter to call arbitrary functions while an object is rebuilt. Loading pickle from a source you do not fully control amounts to running that source's code. When the socket also lacks authentication, every machine that can route to the port becomes such a source.

The 0.5.6 release replaces pickle with versioned, typed MessagePack descriptors that are validated before use. The advisory says the device wrapper type is chosen from a fixed local allowlist, there is no pickle fallback, and both the ZeroMQ and gRPC transport paths are covered.

Who is realistically exposed

Exposure hinges on the bind address. Per the advisory, the transport listens on localhost unless the operator sets a routable address with --host, which is how multi-node deployments let peers connect. The 9.8 score reflects that routable configuration, whereas a stock single-host install with the default bind cannot be reached from other machines.

Affected builds are 0.3.9 through 0.5.5, the 0.5.6 release candidates, and dev branch builds from before PR #5644. The vulnerable decode path first shipped in v0.3.9.

How to check your exposure

Begin with the installed version. This read-only command prints the lmcache package details, including the version, for the Python environment you run it in. Anything from 0.3.9 up to but not including 0.5.6 is affected.

pip show lmcache

Next, look for a listener on the transport port. This read-only command lists listening TCP sockets whose line mentions 5555. A listener on 0.0.0.0 or any non-loopback address means the transport may be reachable from the network, depending on your firewall rules. If you set a custom --port, search for that number instead.

ss -ltnp | grep 5555

Also read your startup commands, service files and Kubernetes manifests for the --host option. A routable address there means the transport is open to anything that can route to that host.

What to do now

This command upgrades the package to the fixed release. Run it in each Python environment that has lmcache installed, then repeat pip show lmcache and confirm the version reads 0.5.6 or higher.

pip install --upgrade "lmcache>=0.5.6"

If you cannot upgrade immediately, the advisory's workaround is to avoid binding the transport to a routable address, and it makes sense to also restrict network access to the port to trusted peers. These are stopgaps, not replacements for the upgrade.

Detection and monitoring afterwards

Because the payload runs during argument decoding, the server may only log a type error for the registration request after the command has already executed, as the advisory describes. Unexpected REGISTER_KV_CACHE type errors in LMCache logs deserve attention, as do connections to the transport port from addresses that are not your own workers.

• Review LMCache logs and network flow logs for that port covering the period before you patched.
• Look for unexpected child processes, new files in temporary directories, or new outbound connections from LMCache hosts.
• Rotate credentials, API keys and tokens that the LMCache process could read if you suspect access.
• Run LMCache as a non-root user with minimal permissions, and keep inference infrastructure off public networks.

If part of this stack sits behind a public website, an outside-in view can add context. A security scan shows what a site exposes publicly, and monitoring can flag certificate, DNS and header changes. Neither replaces patching or network restrictions on internal services, and an outside view cannot see a port that is open only inside your cluster. For the limits of that view, see what outside-in malware detection can and cannot see.

Timeline

Technical sources: the GitHub advisory, the v0.5.6 release and the LMCache blog update.

Sources

This article is based on the public sources below. Details can change as vendors and researchers publish more; check the original advisories before acting on version numbers.

1. CVE-2026-105192 - GitHub Advisory Databasegithub.com

• LMCache
• CVE-2026-105192
• RCE
• deserialization
• LLM infrastructure
• pip