CVE-2026-105192 is an unauthenticated pickle RCE in LMCache multiprocess mode. No fixed release exists; only routable binds are exposed.
What happened
JFrog Security Research disclosed CVE-2026-105192 on 7 October 2026, a critical remote code execution flaw in LMCache, the KV-cache layer used alongside LLM inference servers such as vLLM (we covered the vLLM KV connector flaws). In multiprocess mode, LMCache opens a ZeroMQ ROUTER socket so worker processes can register and share KV cache blocks. That socket has no authentication, and incoming messages are decoded with Python's pickle.loads. A single crafted message is enough to run code as the LMCache process user.
NVD lists a CVSS 3.1 base score of 9.8 (vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). The score comes from JFrog acting as the CNA; NIST had not added its own assessment, and the entry was marked Deferred when we checked on 8 October 2026.
Status as of 8 October 2026: we found no fixed release, and LMCache has not published a security advisory for the flaw (The Hacker News says so, and the repository's GitHub security-advisories list is empty). The latest stable release on GitHub is v0.5.5 (12 September 2026), and JFrog lists it as affected. We found no public proof-of-concept and no report of exploitation. NVD's SSVC data records Exploitation as "None" but Automatable as "Yes". We did not find a CISA KEV listing.
Why it matters
The practical risk depends on one setting: where the multiprocess server listens. JFrog and the CNA text in NVD both state that the default bind address is localhost on port 5555, and that the flaw becomes network-reachable when an operator passes a routable address with the --host flag. JFrog calls that "the documented multi-node setting", the way multi-node deployments let peers connect. JFrog also says LMCache used only inside a vLLM process does not open this port, and that the 9.8 score is for the routable configuration: a stock single-host install that leaves the default bind is not reachable from other machines.
Where that applies, an attacker with network access to the port needs no credentials and no user interaction. JFrog notes that the official container images run as root, so a successful attack on a containerised deployment would run as root inside the container. GPU inference hosts often hold model weights, API keys and cloud credentials, which raises the stakes of any code execution there.
This is the same class of bug that has recurred across AI serving stacks (we covered the LightLLM pickle RCE): ZeroMQ or similar sockets used for internal coordination, with pickle on the wire and an assumption that the network is trusted.
Technical details
According to JFrog, messages use msgpack, and extension code 1 is registered for DeviceIPCWrapper. When the decoder meets that extension code, it calls pickle.loads on the payload during argument decoding, before any validation. The socket offers no CURVE, ZAP or message authentication.
The LMCache source is consistent with this. In v0.5.5, the docstring of lmcache/v1/platform/base/ipc_wrapper.py says all wrappers share "the single msgspec ext code (1)" and describes "pickle-based (de)serialization". Unpickling attacker-controlled bytes lets the sender execute arbitrary Python, which is why NVD tags the issue CWE-502 (deserialization of untrusted data) and CWE-306 (missing authentication).
How one unauthenticated message becomes code execution in LMCache multiprocess mode.
Affected versions: from v0.3.9 (released October 2025, per The Hacker News) through v0.5.5, the v0.5.6 release candidates up to rc3, and the dev branch as of 7 October. JFrog writes that "the decode path shipped in v0.3.9" and is still present in all of those. NVD's affected data lists 0.3.9 with an open upper bound, which agrees.
What defenders should do
- Find multiprocess deployments. LMCache used only inside a vLLM process (the in-process connector) does not open this port, so those setups are not exposed to this CVE. Search for LMCache servers started in multiprocess mode and for anything listening on TCP 5555 (for example
ss -ltnp | grep 5555on the host or inside the container). Check launch scripts, Helm values and Kubernetes manifests for--host. - Check what the bind address is. A
localhostor loopback-only bind matches the default JFrog describes and is not network-exposed. Any routable address,0.0.0.0included, puts the socket on the network. - Restrict reachability now. Per JFrog, do not use
--hostwith routable addresses and keep the port on localhost or trusted networks. Add firewall rules or Kubernetes NetworkPolicies limiting port 5555 to the specific worker pods. The Hacker News notes that firewalling lowers the risk but does not eliminate it, because any permitted peer can still send the message. - Reduce blast radius. Do not run the server as root where you can avoid it, and limit the credentials and cloud roles available to the process.
- Hunt for abuse. No indicators have been published. Look for unexpected connections to port 5555 from hosts that are not inference workers, and for child processes spawned by the LMCache process.
- Watch for a fix. Track the LMCache releases page and the NVD record, and upgrade once a patched release ships. JFrog's longer-term advice is to replace pickle with a safe format and add authentication (CURVE or HMAC), which needs a code change in LMCache.
A separate LMCache CVE
NVD also published CVE-2026-107204 on 7 October, assigned by VulnCheck. It describes a different bug: unauthenticated code execution through a /run_script HTTP endpoint in LMCache through 0.5.5, with a CVSS 4.0 score of 9.3. The record was still in "Received" status when we checked. It is a different component from the ZeroMQ flaw, so closing port 5555 does not address it. The NVD text says the bypass works by recovering real builtins through the injected FastAPI app object, and public GitHub issue #5510 is titled "run_script sandbox escape via FastAPI app object in LMCache internal API server (RCE when enabled)". We have not verified the details beyond that, so check whether any HTTP API server is enabled and reachable in your deployment.
What is still unclear
- Whether the maintainers have acknowledged CVE-2026-105192 or have a fix in progress. We found no repository security advisory or fix pull request.
- Whether the gRPC request transport merged on 16 September (PR #4953, alongside ZMQ) avoids the pickle path, and whether it is enabled by default.
- Whether other reports are valid. Six GitHub issues (#5507 to #5512), filed around 6 October, allege unauthenticated access in other LMCache components, including a coordinator said to default to
0.0.0.0:9300. We have not verified them, and none has a CVE that we found. - Exploitation status. As of 8 October 2026 we found none reported, but that can change quickly for an unauthenticated pickle bug.