// hackerlogs
login+ register
LLM AppSecSupply ChainThreat BriefCriticalCVE-2026-105192

JFrog Published LMCache 9.8. No Fixed Build Is Named.

JFrog published CVE-2026-105192 on 7 October. LMCache multiprocess mode unpickles an unauthenticated message when the host is routable. No fixed version is named.

The short answer

JFrog published CVE-2026-105192 on 7 October 2026. LMCache from 0.3.9 through the current stable 0.5.5 is affected, and the record names no fixed release. Multiprocess mode unpickles an unauthenticated message before the handler runs. Official images run that process as root. The socket stays on localhost unless the operator sets a routable host. No project advisory is posted.

Key takeaways

  • CVE-2026-105192 is JFrog's record, published 7 October 2026 at 09:40 UTC and updated at 17:48 UTC. CVSS 9.8 is the score for multiprocess mode bound to a routable address.
  • The affected range starts at 0.3.9 and has no upper bound. PyPI stable 0.5.5 (12 September) and 0.5.6rc3 (6 October) both sit inside that range. No fixed version is named.
  • The socket binds to localhost unless the operator passes a routable --host. That flag is how the quickstart says multi-node peers connect. A localhost bind is not the 9.8 case.
  • LMCache's security-advisories list was empty on 7 October. Six other issues opened on 6 October by one account are not this CVE and are not confirmed here.
  • vLLM 0.30.0 fixes CVE-2026-105756, a crash from a bad cache salt on LMCache-MP deployments. That patch does not close this socket.

JFrog published CVE-2026-105192 at 09:40 UTC on 7 October and updated the record at 17:48 UTC. LMCache's multiprocess mode, also called distributed mode, opens an unauthenticated socket so workers can share KV cache blocks. One message type is unpickled while the server is still reading arguments, before the handler runs. The code runs as the LMCache process user. The record says official container images run that process as root.

Hacker News on 7 October led with Claude Haiku 5.5, GPT-6 and Intelligent UI, and Docker Agent. US X trends at 22:20 UTC were a token hashtag, politics, baseball, then Haiku 5.5 and, further down, GPT-6. Those are launches. The operator record is the CVE, and The Hacker News carried it the same day. LMCache has not posted an advisory. The repository security-advisories list was empty on 7 October.

Critical Critical where multiprocess mode is bound to a routable address. The score is 9.8. A localhost bind is not that scenario.

Three panels for the unpatched LMCache multiprocess flaw: an unauthenticated socket that unpickles before the handler, a 9.8 record with no fixed version, and the operator action to keep the bind off a routable host.

What JFrog's record actually says.#

The package is lmcache on PyPI. The affected range starts at 0.3.9, uploaded 29 October 2025, and the record sets no upper bound. PyPI showed 0.5.5 as the newest stable, uploaded 12 September 2026. The newest candidate on the index, 0.5.6rc3, uploaded 6 October at 23:33 UTC, the evening before the CVE. Both sit inside a range that does not end.

The weakness classes are CWE-502, deserialization of untrusted data, and CWE-306, missing authentication for a critical function. The CVSS 3.1 vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. The scenario line on the record is multiprocess mode bound to a routable address, the documented multi-node deployment. Messages are msgpack. One extension is handed to a deserializer that calls pickle while arguments are still being decoded.

The v0.5.5 quickstart starts that server with --host localhost and names port 5555 as the default. It also says a remote host is how peers on another machine connect. The CVE uses the same sentence: the transport binds to localhost unless the operator sets a routable --host.

The package clock and the impact clock.#

The package clock started on 29 October 2025, when 0.3.9 uploaded with the multiprocess path the record now marks affected. The disclosure clock is 7 October 2026, 09:40 UTC, when JFrog, the CNA, published the CVE. That is more than eleven months of builds with no fixed version on the record and no project advisory beside it.

The impact clock is narrower than the version range. It starts when --host is an address another machine can reach. A default localhost bind does not meet the 9.8 scenario. A multi-node deployment does, because that is how peers are supposed to connect. Any host that can still open the socket can run code as the process user. If that user is root, the blast radius is the host.

The v0.5.5 Kubernetes page does not itself set the multiprocess host. It points at the vLLM production stack. Do not invent a bind from a Helm pointer. Read the values you deployed. The flag that matters is the one on the LMCache multiprocess server, not the HTTP port of the model server sitting next to it.

  1. lmcache 0.3.9 uploads to PyPI. The CVE later marks this version as the start of the affected range, with no upper bound.
  2. 0.5.5 uploads, still the newest stable on 7 October. The v0.5.5 quickstart binds the multiprocess server to localhost unless the operator sets a host.
  3. vLLM 0.30.0 uploads. It later matches the fix line for a different bug, CVE-2026-105756, a crash from a bad cache salt.
  4. 0.5.6rc3 uploads at 23:33 UTC. The same day, one GitHub account opens six other LMCache security issues. They are not this CVE.
  5. 09:40 UTC: JFrog publishes CVE-2026-105192, CVSS 9.8, no fixed version. 17:48 UTC: the record is updated. The project advisories list is empty.

What this is not.#

It is not a bug in every LMCache process. The record's scenario is multiprocess mode with a routable bind. A server that never leaves localhost is a different exposure.

It is not CVE-2026-105756. That vLLM record, published 5 October, is an uncaught error: a malformed cache salt can kill EngineCore on deployments that use the LMCache multiprocess connector. Fixed in vLLM 0.30.0. Rated as a denial of service. Patching the engine does not authenticate the cache socket.

It is not the six issues opened on 6 October, numbers 5507 through 5512, by one account. Those titles allege other unauthenticated paths, including a coordinator bind and an internal API. They were open, without a CVE, when JFrog's record went out. This brief does not confirm them.

It is not a claim that the v0.5.5 Kubernetes guide binds every interface. That page delegates to the vLLM production stack. Check the host you actually passed.

It is also not a named intrusion. Nothing in the CVE, and nothing on the empty advisories list, says the socket has been used in the wild. Absence of a victim is not a patched build.

What to do.#

  1. Find every LMCache multiprocess server and read its --host. Localhost is the quickstart default. Anything routable is the 9.8 scenario, including the multi-node case the project documents so peers can connect.
  2. Do not treat 0.5.5 or 0.5.6rc3 as the fix. Stay on a bind that other machines cannot open until JFrog or LMCache names a patched release. A firewall that still lets untrusted hosts through is not that release.
  3. Assume the process user is the blast radius. The record says official images run it as root. If a routable port was reachable, rotate keys and tokens that lived on that host.
  4. Patch vLLM to 0.30.0 or later for CVE-2026-105756 if you use the LMCache multiprocess connector. Then keep going. That CVE is a crash, not this one.
  5. Do not merge the six 6 October issues into this ticket. Triage them on their own, and do not brief a board that they are confirmed just because the titles are loud.
  6. Ask LMCache for an advisory with an upper bound. Until that sentence exists, the package clock is still open and the impact clock is every routable bind you have not pulled back.

The disclosure clock struck at 09:40 UTC. The package clock has not stopped. The impact clock is the host flag, not the version badge on the image.

Frequently asked

Does a localhost bind make this safe?

The CVE scores 9.8 for multiprocess mode bound to a routable address. The record says the transport binds to localhost unless the operator sets a routable --host, which is how multi-node peers connect. A process that never leaves localhost is outside that scenario. Any host that can open the socket is inside it. A firewall that still allows cluster peers does not remove the miss.

Is 0.5.5 or 0.5.6rc3 the fix?

No fixed version is named. PyPI's newest stable, 0.5.5, uploaded on 12 September. The newest candidate, 0.5.6rc3, uploaded on 6 October, the day before the record. The affected range starts at 0.3.9 and has no upper bound. A newer tag is not a fix until JFrog or LMCache says the range ends.

Did patching vLLM close this?

No. CVE-2026-105756 is a different bug. Before vLLM 0.30.0, a single request with a malformed cache salt could crash EngineCore on deployments that use the LMCache multiprocess connector. That record published on 5 October. It is a denial of service, not code execution, and the upload of 0.30.0 was 22 September. Patch it, and still treat the LMCache socket as open.

Are the six GitHub issues from 6 October the same bug?

They are separate reports, opened by one account, and they were still open when this brief was written. They allege other unauthenticated paths. They have no CVE and no maintainer confirmation in the record JFrog published. Do not close CVE-2026-105192 because you triaged a different issue, and do not treat those titles as confirmed.

Sources

  1. CVE-2026-105192 JFrog (CNA) · 2026-10-07
  2. lmcache on PyPI PyPI · 2026-09-12
  3. CVE-2026-105756 CVE Program · 2026-10-05

Related