On 7 October 2026 JFrog Security Research published CVE-2026-105192, a critical bug in LMCache, and The Hacker News reported it the same day. As of the morning of 12 October, no release on PyPI or GitHub removes the vulnerable path. An open pull request proposes a fix and has not been merged.
What LMCache is, and where the socket sits
The PyPI record describes LMCache as an LLM serving extension that cuts time to first token and raises throughput, especially on long contexts. Projects such as vLLM use it as a KV cache layer: it keeps already-computed attention state so a later request can reuse it.
JFrog’s advisory is about multiprocess mode, which it also calls distributed mode. In that mode LMCache opens an unauthenticated ZeroMQ socket so worker processes can register and share cache blocks. The intended clients are other LMCache processes. JFrog says the socket has no CURVE, ZAP, password, or message authentication. LMCache used only inside a vLLM process does not open the port. The transport binds to localhost unless the operator sets --host to a routable address, which is how multi-node setups let peers connect.
JFrog scores the routable case CVSS 9.8, critical. It says a stock single-host install that leaves the default bind is not reachable from other machines. The advisory says a message on that socket is deserialized with Python’s pickle, which runs with the privileges of the LMCache process, and that the decode happens before the request handler runs. The default port in the advisory is 5555. JFrog says the path shipped in v0.3.9 and was still present in v0.5.5, in the 0.5.6 release candidates through v0.5.6rc3, and on the dev branch as of 7 October. This article does not repeat the advisory’s proof-of-concept.
What is true on 12 October
The advisory’s “no fixed version” line is dated 7 October. The tree this morning is the same on the point that matters:
- PyPI’s latest stable release is 0.5.5, uploaded 12 September 2026. The newest pre-release is 0.5.6rc4.dev27, uploaded 2026-10-10T05:54:23Z. The base IPC wrapper inside that pre-release source archive still unpickles its payload.
- The same file on the v0.5.5 tag, on the 0.5.6rc4 tag, on
master, and on the default branchdevis byte-for-byte the same, and it still unpickles.devwas read at 05:48 UTC on 12 October. - GitHub’s security-advisory list for the repository was empty. The releases page has nightly builds dated 11 October and a 0.5.6rc4 pre-release dated 10 October. None of those is a security release.
- Pull request 5644, “[Security][MP] Remove pickle from device IPC descriptors (CVE-2026-105192),” was opened on 11 October by GitHub user maobaolong and updated at 04:40 UTC on 12 October. It is open, not merged, and GitHub marked it mergeable. The author says workers and servers would have to be upgraded together, because old pickled descriptors would be rejected, and that engine-driven pickle handling and authentication on the socket are outside the change.
Until that lands in a release, installing 0.5.5 or 0.5.6rc4.dev27 does not remove the path JFrog described.
Official images and root
JFrog says official container images run the LMCache process as root, so anything that does execute runs as root. The Dockerfile on dev and the Dockerfile on the v0.5.5 tag set no USER. They build FROM an NVIDIA CUDA base image. That is consistent with JFrog’s claim. It is not a running-container check.
What to do
JFrog’s operator guidance, still the published advice while no release contains a fix:
- Leave the default bind alone. Do not set
--hostto a routable address. - Keep the multiprocess port on localhost or on a cluster network you trust. JFrog says a firewall reduces who can connect, and that any host which can still open a connection can run code as the LMCache user.
- A copy of LMCache that stays inside one vLLM process does not open this port. That setup is not the exposed case.
- Do not treat pull request 5644 as something you can pin. It is not in a release, and its author says it does not add authentication.
The Hacker News story also mentions other LMCache reports from 6 October and a separate, already fixed vLLM crash bug. Those are outside this CVE. They are not confirmed here, and they are not a patch for CVE-2026-105192.

The Campfire
No commentsNobody has pulled up a log by this one yet. Be the first to say what you make of it.
Held for the desk. It appears after a look.