If you run LLM inference with vLLM and use LMCache to share cached data between workers, you should check one thing today: what address your LMCache server listens on. A critical flaw with no patch turns that single setting into the difference between a safe deployment and an open door.
What was reported
According to The Hacker News, JFrog disclosed a vulnerability in LMCache on October 7. It is tracked as CVE-2026-105192 and scored 9.8 out of 10. LMCache is open-source software that speeds up LLM servers such as vLLM.
The bug is in LMCache’s multiprocess mode, where the cache runs as its own server and LLM workers talk to it over ZeroMQ. One network message to that server can run commands as whatever user the LMCache process runs as. No login is needed.
The affected range is LMCache 0.3.9 (released October 2025) through 0.5.5, the latest stable release. The 0.5.6 release candidates and the development branch are also affected. No fixed version exists.
JFrog’s researcher Yuval Moravchick found the flaw.
How the bug works
The ZeroMQ socket that worker processes use to register and share cached data has no authentication. One type of message is decoded with pickle, a Python format that can carry code and run it during decoding.
The server unpacks that message while it is still reading the message’s arguments, before it checks the message type. So a crafted message runs the sender’s code. This is a classic pattern: untrusted network input goes straight into pickle.
The impact depends on privileges. The code runs with the rights of the LMCache process, and JFrog says that on the project’s official container images, that process runs as root.
Whether you are exposed comes down to one setting
By default, the multiprocess server listens only on localhost, so other machines cannot reach it. It becomes reachable when an operator starts it on a routable address. That is common in multi-node setups that share a cache across machines.
The source also reports that LMCache’s own example Kubernetes deployment starts the server listening on every network interface. A copy of LMCache running inside a single vLLM process does not open the port at all.
The 9.8 score is the rating JFrog gives a server bound to a routable address. A localhost-only deployment is a very different situation.
No patch, no advisory, no way to check
Three things make this worse than a typical bug disclosure:
- There is no patched release.
- LMCache has not published a security advisory for the flaw.
- JFrog’s advisory gives operators no way to tell whether a server has already been attacked.
JFrog’s advice is to avoid giving the multiprocess server a routable address and to keep its port on the local machine or a trusted cluster network. A firewall limiting who can reach the port lowers the risk but does not remove it, because any host that can still open a connection can run code.
Other reports and a related vLLM fix
The source describes some related noise. On October 6, a GitHub user opened six more LMCache security reports. They allege unauthenticated access to cached data across tenants and to several network services that execute commands without a login.
Treat those with caution. They come from one account, rest on proof-of-concept claims, and have no CVE, no maintainer confirmation and no fix. One of them points at a default that has already changed: an admin HTTP server that listened on every interface in 0.5.5 listens only on the local host in the 0.5.6 release candidates.
Separately, vLLM fixed a related problem in version 0.30.0, released September 22. Before that, one request with a malformed cache_salt value could crash the engine on deployments using the LMCache multiprocess connector. That is CVE-2026-105756, rated 6.5, and it is a denial-of-service bug that does not allow code execution.
The source also notes that handing data from an unauthenticated network socket to pickle is the same core mistake researchers found across other AI inference frameworks in November 2025, in a group of flaws they called ShadowMQ. Whether LMCache’s code shares a source with those projects has not been established.
My take
Everything above is from the reporting. What follows is my own analysis.
The part that bothers me most is not the bug itself but the combination around it. The vulnerable mode is the one you reach for when you scale out. The example Kubernetes manifest binds to all interfaces. The official image runs as root. And there is no patch to apply. Each of those alone is manageable. Together, they mean a team that copied the example deployment may be running a root-level, unauthenticated code execution endpoint without ever having decided to.
I would also not take comfort in the phrase cluster network. Inference clusters often sit next to other workloads, and a flat pod network means any compromised pod can reach that port. Trusted is doing a lot of work in that advice.
Finally, the lack of any detection guidance means you have to reason from exposure. If the server was ever reachable by something you do not fully trust, I would assume it could have been hit.
What I would do now
These are my suggestions, built on JFrog’s advice:
- Find your LMCache multiprocess servers. Search your configs, Helm charts and manifests for the multiprocess server, and note which address and port each one binds to.
- Change any routable binding. If a server listens on all interfaces or another routable address, move it to localhost or a tightly controlled cluster network where you can.
- Restrict access at the network layer. Use Kubernetes NetworkPolicies or security groups so only the specific vLLM workers can open connections to the port. This is not a full fix, since any allowed host can still send the malicious message, so keep the allowed set small.
- Drop privileges. If you can run the LMCache container as a non-root user, do it. The code runs with the process’s rights, so this limits the damage.
- Review what the process can reach. Check which secrets, credentials, model files and network paths that container has access to. If an exposed server might have been reached, treat those as at risk and consider rotating them.
- Watch network logs. Look for unexpected connections to the LMCache port and unusual child processes in the container, even though there is no published indicator to hunt for.
- Track the project. Watch for a fixed release or advisory, and keep an eye on the unconfirmed reports, since some may turn out to matter.
- Update vLLM. If you use the multiprocess connector, moving to 0.30.0 or later closes the denial-of-service issue, CVE-2026-105756.
If your LMCache runs inside a single vLLM process, the source says the port is not opened at all, so this particular flaw should not apply to you. For everyone else, the work today is simple: find the listener, shrink who can reach it, and limit what it can do if someone does.
Sources
- Unpatched Critical LMCache Flaw Lets Unauthenticated Attackers Run Code Remotely — The Hacker News, 2026-10-07
