LMCache RCE Has No Fix—Routable Port 5555 Can Run Code as Root

On October 7, 2026, JFrog Security Research’s advisory disclosed CVE-2026-105192, rated the routable LMCache multiprocess flaw CVSS 9.8 and listed no fixed release: an unauthenticated message to the transport on default port 5555 can execute code as the LMCache process user, which is root in official container images. The immediate risk depends on who can reach that port and which privileges the process holds.

The published CVE record names JFrog Security Research as coordinator and identifies unsafe deserialization and missing authentication. An LMCache instance embedded in a vLLM process does not open the affected transport, while a multiprocess server left on its default localhost bind cannot be contacted directly from another host. A routable bind creates a possible cross-host path; network controls determine who can use it. With no fixed release identified, that deployment distinction is the immediate exposure check.

Where the affected network path exists

Multiprocess mode gives LMCache workers a shared cache server. Workers register and exchange cached key-value blocks over an unauthenticated ZeroMQ socket. Cross-host deployments can set the server’s --host option to an address other machines can reach. The distinction for operators is therefore the effective listener and the routes to it, not merely the presence of LMCache in an environment.

• Embedded use: If LMCache runs solely inside a vLLM process, there is no multiprocess server socket for this vulnerability to target.
• Loopback-only server: A multiprocess server listening on localhost is inaccessible directly from another machine. Local processes can still reach it, so this configuration assumes the host’s other workloads belong inside the trust boundary.
• Routable server: A server bound to a network-facing address can receive cross-host traffic. The relevant question is whether only intended LMCache workers can connect, or whether other workloads, neighboring nodes or external networks can reach the same port.

Check the live process arguments or server configuration for --host and --port, then inspect the address on which the ZeroMQ transport actually listens. Compare that listener with firewall rules, cloud security groups, Kubernetes services and any forwarding rules. The configured port may differ from the default; finding a closed default port alone cannot establish that a deployment is safe. A routable bind also does not establish public internet exposure by itself: the permitted network paths define the actual set of potential senders.

Which releases are affected, and why a handler cannot stop this

An October 7 report by The Hacker News places the vulnerable decode path from LMCache version 0.3.9 through stable release 0.5.5, in the 0.5.6 release candidates and in the development branch, with no patched version reported. That range identifies software containing the flaw, while the bind and reachability check identifies deployments exposed to cross-host messages. Upgrading to an affected release candidate does not remove the vulnerable path.

The server accepts messages encoded with msgpack, but one extension type is passed to a Python deserializer that calls pickle.loads. Deserialization happens while request arguments are being decoded, before the intended handler runs. Because pickle can execute code at that point, a later type error or rejected request cannot undo the execution. The vulnerable endpoint is the workers’ ZeroMQ transport; an HTTP listener that may also be configured for LMCache is a different service and must not be mistaken for the port under review.

What root in the container means

The code executes with the privileges of the LMCache server process. In the official container images, that process runs as root, making the privilege consequence concrete for deployments using those images. Operators running a custom image or process account should check the actual runtime user rather than infer it from the software version.

Root inside a container does not automatically mean root on its host. The files the container can access, its mounts, network permissions and runtime settings shape what executed code could affect beyond the LMCache process. Running the service as an unprivileged user can reduce that authority, but it does not change the unsafe decoder or authenticate the socket. The reachability decision remains important even where the process account has been restricted.

Containing the risk until a fixed release ships

Where cross-host sharing is unnecessary, keep the multiprocess transport bound to localhost. Where worker hosts must reach a standalone server, confine the listener to a trusted cluster network and allow traffic only from the hosts that need to use it. Apply those restrictions to the port the server actually uses, including any mapped or forwarded port, and assess reachability from the network segments that could otherwise contact it.

Network filtering changes which machines can send a message; it does not make messages from permitted machines safe. A shared cluster network with unrelated workloads may therefore leave more potential senders than the operator intended. Review service exposure, node-level rules and container networking together, because a rule at only one layer may not describe the path packets take to the listener. Removing a public route is valuable, but a private route open to untrusted peers still leaves the execution path available.

A permanent software fix should stop deserializing untrusted network bytes with pickle and authenticate the transport. Until a corrected release is published, operators who need multiprocess sharing must treat access to that socket as access to the LMCache process itself.