Critical unpatched flaw in LMCache allows remote code execution on networked servers

The JFrog security research team disclosed a critical vulnerability in LMCache, an open source project, on October 7, 2026. Tracked as CVE-2026-105192, it has a CVSS score of 9.8 out of 10. According to JFrog's advisory, the flaw sits in LMCache's multiprocess (distributed) mode and allows remote code execution without authentication on a server reachable over the network. No fixed version was available when the advisory was published.

LMCache is a KV cache layer for software that serves large language models. When a language model reads text, it produces intermediate computations for each piece of it; the KV cache is where those computations are stored. LMCache keeps this data across GPU memory, system memory, disk and remote storage so the same text does not have to be computed again, with the aim of a faster first response in long conversations and document-based (RAG) applications. It is most often used alongside open source model servers such as vLLM. That makes the issue directly relevant to administrators who run language models on their own servers.

The flaw sits in an unauthenticated network channel

According to JFrog's advisory and the CVE record, LMCache's multiprocess mode opens a ZeroMQ-based network channel so worker processes can register and share cache blocks. The channel has no password or other authentication. One type of incoming message is decoded with Python's pickle format. Because decoding pickle data can also run commands embedded in it, anyone who can reach this channel can run code on the server with a single crafted message. The decoding happens before the request itself is handled. The code runs with the privileges of the LMCache process; according to the advisory, the official container images run that process as root.

Affected versions and exposed setups

According to the record, the vulnerable code arrived in version 0.3.9. JFrog says it is still present in 0.5.5, the latest stable release on PyPI, in the release candidates for 0.5.6, and in the development branch as of October 7.

How serious the risk is depends on how LMCache is deployed. According to JFrog, the channel accepts connections only from the same machine (localhost) by default, so a single-machine install with default settings is not reachable from other hosts. In setups where several servers share the cache, administrators give a network-reachable address with the --host option; the 9.8 score was calculated for that configuration. The channel's default port is 5555. JFrog also notes that when LMCache is used only inside the vLLM process, this port is not opened.

Recommended steps until a fix arrives

Until a fixed release is available, JFrog recommends not setting --host to a network-reachable address and keeping the port on the same machine or on a trusted cluster network. According to the advisory, a firewall reduces exposure, yet any host that can connect to the port can still run code. Administrators may therefore want to check whether they use multiprocess mode, how --host is set, and which machines can reach port 5555.

For a lasting fix, JFrog recommends that the project stop decoding network data with pickle, add authentication to the ZeroMQ channel, and refuse to bind to a network-reachable address unless authentication is configured.

The vulnerability was found and scored by JFrog. At the time of writing, LMCache's GitHub page had no published security advisory on the issue, and the latest release on PyPI was still 0.5.5. Since JFrog's advisory includes technical details of the flaw, it is sensible to apply the mitigations on network-exposed installs without delay and to watch LMCache's GitHub and PyPI pages for new releases. For a fuller picture, follow evaluations from independent researchers as well.

Sources: JFrog: LMCache security advisory (JFSA-2026-001694382), CVE record: CVE-2026-105192, LMCache GitHub repository.