plaincve:~$

// threat brief

CVE-2026-105192

LMCache multiprocess ZMQ transport pickle deserialization: unauthenticated remote code execution, fixed on the dev branch but no stable release yet

CVSS
9.8 CRITICAL
CISA KEV
Not listed
Weakness
CWE-502 · CWE-306
Topics
AI security · Infrastructure

PlainCVE Team · Published 2026-10-11 · Updated 2026-10-12 · AI-assisted · Press brief ↓

AI review 2026-10-12 (not human-reviewed)Command tests: none yetReproduced: not yetVerification record ↓

LMCache's multiprocess mode unpickles network messages with no login, so anyone reaching its port can run code. Fixed on the dev branch; no stable release yet.

Who is affectedDeployments running LMCache v0.3.9 or later (through v0.5.5, v0.5.6rc3 and the dev branch as of 2026-10-07) in multiprocess (standalone server) mode, bound with --host to an address other machines can reach.
What happensAnyone who can reach the transport port (default 5555) can run code as the user the LMCache process runs as with a single message. According to the CNA (JFrog), official container images run that process as root.
What to do nowThe maintainers merged a fix into the dev branch on 2026-10-12, and as of 2026-10-12 no stable release includes it; the nightly pre-releases built from dev and published on GitHub Releases from that day (0.5.6.dev200) do include it, but they are not stable releases. When you upgrade, workers and the multiprocess server must be upgraded together. Until then, following the advice in JFrog's advisory (that page contains exploit code, so PlainCVE does not link to it), do not set --host to a routable address; keep the port on localhost or a trusted cluster network. A firewall narrows the risk but does not remove it.
Affected versionsAll versions from v0.3.9 onward (CVE record, 0.3.9 ≤ *); JFrog's advisory body says this includes the latest PyPI release v0.5.5, the v0.5.6 release candidates up to v0.5.6rc3, and the dev branch as of 2026-10-07 (JFrog's advisory page header says ">= 0.3.9"; that page contains exploit code, so PlainCVE does not link to it); v0.5.6rc4, released 2026-10-10, predates the fix merge, so PlainCVE's assessment is that it does not include the fix either
Fixed versionsNo release includes the fix yet (as of 2026-10-12); the fix was merged into the dev branch on 2026-10-12 (PR #5644, commit 160b6de; that page contains exploit code, so PlainCVE does not link to it); the nightly pre-releases built from dev and published on GitHub Releases from 2026-10-12 (0.5.6.dev200, commits 6d1aa31 / 762df68, both after 160b6de) include the fix, but they are not stable releases
CVSS vector
Show full vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Timeline
  • First public 2026-10-07

Blue team playbook

Check, fix / mitigate, respond, harden. Matching the affected versions does not mean you were compromised, and a check that finds nothing does not prove you are safe; each item says what it can and cannot show. Tagged steps point to where the attack flow below can be stopped.

DETECTCheckAm I affected? Any signs of compromise?
  1. 01Check your version and mode

    Where to run: on the host or inside the container that runs LMCache, in the same Python environment (venv) LMCache uses; run elsewhere, it may find nothing or report a different version. v0.3.9 and later (including v0.5.5 and v0.5.6rc3) are affected. Using LMCache only inside a vLLM process does not open this port; the risk exists only in multiprocess (standalone server) mode.

    Read-only check
    pip show lmcache | grep -i '^version'
  2. 02Check which address the transport port is bound to

    Where to run: on the host that runs the LMCache server; with containers or Kubernetes, run it inside that container's or Pod's network namespace. The -p option needs root to show process names. If port 5555 (or your custom port) listens on 0.0.0.0 or another routable address, other machines may reach it. LMCache's own CLI quick-start binds to 0.0.0.0:5555, and according to The Hacker News its example Kubernetes deployment also listens on every interface.

    Read-only check
    ss -ltnp | grep ':5555'
    Step 1
  3. 03JFrog's advisory gives no way to detect compromise

    According to The Hacker News, JFrog's advisory (that page contains exploit code, so PlainCVE does not link to it) gives no way to tell whether a server has already been attacked. PlainCVE's suggestion: if the port was ever exposed, assume compromise cannot be ruled out.

    Step 4
MITIGATEFix / mitigatePatch; block it if you cannot patch yet
  1. 01Do not set --host to a routable address

    JFrog's advisory (that page contains exploit code, so PlainCVE does not link to it) advises: until a fixed release ships, keep the multiprocess port on localhost or a trusted cluster network.

    Step 1
  2. 02Restrict the port with a firewall

    JFrog's advisory (that page contains exploit code, so PlainCVE does not link to it) notes this only reduces who can connect; any host that can reach the port can still run code as the LMCache user.

    Step 1Step 2
RESPONDRespondIf you find signs of compromise
  1. 01Treat exposed hosts as possibly compromised

    PlainCVE's suggestion (the sources give no response guidance): isolate the host or container, rebuild from a clean image, and rotate credentials it could access. With official images, the CNA says the process runs as root, so the whole container may be affected.

    Step 4
HARDENHardenPrevent the next one
  1. 01Run LMCache as a non-root user

    PlainCVE's suggestion: code runs as the LMCache process user, so lowering that user's privileges limits the damage.

    Step 4
  2. 02Keep inference-cluster internal ports off untrusted networks

    PlainCVE's suggestion: don't copy documentation examples that bind to 0.0.0.0 as-is; keep node-to-node traffic on an isolated network segment.

    Step 1Step 2
Full remediation steps and notes

There is no released fixed version: the maintainers merged fix PR #5644 into the dev branch on 2026-10-12 (that page contains exploit code, so PlainCVE does not link to it), but as of 2026-10-12 the latest PyPI release is still v0.5.5, and the latest release candidate on GitHub, v0.5.6rc4 (2026-10-10), predates the merge. From 08:21 on 2026-10-12, GitHub Releases published nightly pre-releases built from dev (0.5.6.dev200, commits 6d1aa31 and 762df68); GitHub’s comparison shows both commits come after fix commit 160b6de, so they include the fix, but nightlies are pre-releases, not stable releases. According to The Hacker News, LMCache had not published a security advisory at disclosure. The bind and firewall advice below comes from JFrog’s advisory (that page contains exploit code, so PlainCVE does not link to it), not from LMCache; the checking and monitoring steps are PlainCVE’s suggestions.

  1. Check whether it listens externally. On the host running the LMCache server (or inside the container’s or Pod’s network namespace), run ss -ltnp | grep ':5555' (substitute your port if you changed it; -p needs root to show process names). 0.0.0.0 or an external IP means other machines may be able to connect.
  2. Move it back to localhost or a trusted network. Remove any --host pointing at a routable address, or bind only to an isolated cluster segment. For Kubernetes, check whether you reused the example that listens on all interfaces.
  3. A firewall is only a supplement. It reduces which hosts can connect, but any host that can reach the port can still run code.
  4. Watch for a release that includes the fix. As of 2026-10-12, no stable release or release candidate (including v0.5.5 and v0.5.6rc4) includes the fix, so upgrading to those does not solve this; only the nightly pre-releases built from dev since 2026-10-12 (0.5.6.dev200) include it, and they are not stable releases. The maintainers say legacy pickle descriptors are rejected after the fix, so workers and the multiprocess server must be upgraded together.

Attack flow

Read left to right: this is the order the attack happens in. A blue shield means the step can be stopped; the earlier, the better. Click an icon for details.

Read top to bottom: this is the order the attack happens in. A blue shield means the step can be stopped; the earlier, the better. Tap an icon for details.

LMCache multiprocess ZMQ transport pickle deserialization: unauthenticated remote code execution, fixed on the dev branch but no stable release yet: 1. Finds a reachable LMCache transport port → 2. Sends a single unauthenticated message → 3. The server calls pickle.loads while decoding arguments → 4. Attacker's code runs as the LMCache process userCVE-2026-105192 · LMCache multiprocess ZMQ transport pickle deserialization:unauthenticated remote code execution, fixed on the dev branch but no stable release yetAttackerYour systemFinds a reachable LMCache transport port — Other machines can reach it only in multiprocess mode when the operator bound it to a routable address with --host (default port 5555). The default bind is localhost. 1Finds a reachableLMCache transportportSends a single unauthenticated message — The ZeroMQ socket has no CURVE, ZAP, password or message authentication, so no credentials are needed. 2Sends a singleunauthenticatedmessageThe server calls pickle.loads while decoding arguments — msgpack extension code 1 is handed to pickle to rebuild objects, and this happens while arguments are being decoded, before the request handler runs. 3The server callspickle.loads whiledecoding argumentsAttacker's code runs as the LMCache process user — According to the CNA (JFrog), official container images run LMCache as root, so code would run as root there. 4Attacker's coderuns as theLMCache processuserAttack pathCan be stopped herePlainCVE · plaincve.date/en/vulns/cve-2026-105192-lmcache-zmq-pickle-rce · CC BY 4.0
LMCache multiprocess ZMQ transport pickle deserialization: unauthenticated remote code execution, fixed on the dev branch but no stable release yet: 1. Finds a reachable LMCache transport port → 2. Sends a single unauthenticated message → 3. The server calls pickle.loads while decoding arguments → 4. Attacker's code runs as the LMCache process userCVE-2026-105192 · LMCache multiprocessZMQ transport pickle deserialization:unauthenticated remote code execution,fixed on the dev branch but no stabl…Finds a reachable LMCache transport port — Other machines can reach it only in multiprocess mode when the operator bound it to a routable address with --host (default port 5555). The default bind is localhost. 1AttackerFinds a reachable LMCachetransport portSends a single unauthenticated message — The ZeroMQ socket has no CURVE, ZAP, password or message authentication, so no credentials are needed. 2AttackerSends a single unauthenticatedmessageThe server calls pickle.loads while decoding arguments — msgpack extension code 1 is handed to pickle to rebuild objects, and this happens while arguments are being decoded, before the request handler runs. 3Your systemThe server calls pickle.loadswhile decoding argumentsAttacker's code runs as the LMCache process user — According to the CNA (JFrog), official container images run LMCache as root, so code would run as root there. 4Your systemAttacker's code runs as theLMCache process userAttack pathCan be stopped herePlainCVE · CC BY 4.0plaincve.date/en/vulns/cve-2026-105192-lmcache-zmq-pickle-rce
Free to use in reporting and teaching under CC BY 4.0. Attribution is already on the image.
  1. Attacker

    Finds a reachable LMCache transport port

    Other machines can reach it only in multiprocess mode when the operator bound it to a routable address with --host (default port 5555). The default bind is localhost.

    Defense: Per the advice in JFrog's advisory (that page contains exploit code, so PlainCVE does not link to it), do not set --host to a routable address; keep the port on localhost or a trusted cluster network.

  2. Attacker

    Sends a single unauthenticated message

    The ZeroMQ socket has no CURVE, ZAP, password or message authentication, so no credentials are needed.

    Defense: Restrict the port with a firewall. JFrog's advisory (that page contains exploit code, so PlainCVE does not link to it) notes this only narrows who can reach it; any host that can connect can still run code.

  3. Your system

    The server calls pickle.loads while decoding arguments

    msgpack extension code 1 is handed to pickle to rebuild objects, and this happens while arguments are being decoded, before the request handler runs.

    Defense: The maintainers' fix (merged into the dev branch) removes pickle here and uses typed MessagePack descriptors instead. No stable release includes it yet; the nightly pre-releases built from dev since 2026-10-12 (0.5.6.dev200) include it (not a stable release). Workers and the multiprocess server must be upgraded together.

  4. Your system

    Attacker's code runs as the LMCache process user

    According to the CNA (JFrog), official container images run LMCache as root, so code would run as root there.

    Defense: PlainCVE's suggestion: run LMCache as a non-root user to limit the damage if it is compromised.

Who is affected

ConditionAffected?
LMCache v0.3.9 and all later versions (CVE record; JFrog’s advisory header says ”>= 0.3.9” and its body says this includes v0.5.5, the latest PyPI release, v0.5.6rc1–rc3 and the dev branch as of 2026-10-07; that page contains exploit code, so PlainCVE does not link to it; v0.5.6rc4, released 2026-10-10, predates the fix merge), in multiprocess mode bound with --host to a routable addressAffected; remote code execution from other machines
Same versions, multiprocess mode, default localhost bindNot reachable from other machines (see PlainCVE’s analysis below)
LMCache used only inside a vLLM processDoes not open this port
Before v0.3.9The multiprocess transport first shipped in v0.3.9
Fixed versionNo stable release yet; the fix was merged into the dev branch on 2026-10-12 (PR #5644; that page contains exploit code, so PlainCVE does not link to it); nightly pre-releases built from dev since 2026-10-12 (0.5.6.dev200) include it, but are not stable releases

A remote attack needs all of these: LMCache running in multiprocess (standalone server) mode, the operator binding it to a routable address with --host (which is how multi-node deployments let peers connect), and the attacker being able to reach the transport port (default 5555). No account or password is needed.

Note that LMCache’s own CLI documentation has a quick-start command that binds to 0.0.0.0 on port 5555, and according to The Hacker News its example Kubernetes deployment also listens on every network interface. PlainCVE’s analysis: deployments that copied those examples in multiprocess mode are likely in the exposed configuration.

Local risk (no primary source assesses this): the CVE record and JFrog’s advisory (that page contains exploit code, so PlainCVE does not link to it) only say the default bind is localhost and other machines can’t reach it; TheHackerWire (a secondary source) says that with the default bind the attack surface is limited to local privilege escalation or access from an already compromised host. PlainCVE’s analysis: with the default localhost bind, other users or processes on the same host may still be able to reach the server.

How it works

LMCache is a caching tool for large language model inference. It lets several worker processes share the KV cache (intermediate results stored while a model generates output). In multiprocess mode it opens a ZeroMQ socket (ZeroMQ is a library programs use to send each other messages) so workers can register and share cache blocks. This socket has no authentication at all: no CURVE, no ZAP, no password and no message authentication.

Incoming messages are decoded with msgpack. LMCache defines a msgpack extension type (code 1) and hands it to Python’s pickle.loads to rebuild an object. pickle is Python’s object storage format, and loading it can run arbitrary code, which is why it must never be used on data from unknown senders. Worse, this happens while the server is still decoding the request’s arguments, before the request handler has even started.

The result: a single unauthenticated message can run code as the user the LMCache process runs as. The CNA (JFrog) says official container images run that process as root. The weakness types are CWE-502 (deserialization of untrusted data) and CWE-306 (missing authentication for a critical function). In LMCache’s own repository, the v0.3.9 tag contains this pickle-loading code, and at the v0.5.5 tag DeviceIPCWrapper still uses pickle and shares extension code 1.

The flawed approach (conceptual illustration, not the original source code):

Show code example(python)
def ext_hook(code, data):
    if code == 1:
        return pickle.loads(data)  # bytes from anyone on the network get rebuilt, code and all

A safer approach (conceptual illustration, not the maintainers’ code; the maintainers’ fix on the dev branch uses versioned, typed MessagePack descriptors and picks a handler from a fixed allowlist, with no pickle):

Show code example(python)
def ext_hook(code, data):
    if code == 1:
        # Parse a fixed set of plain data fields; never rebuild arbitrary objects
        return DeviceHandle.from_plain_fields(msgpack.unpackb(data))
# ...and verify who the peer is before accepting any message

Timeline

DateEvent
2025-10-29v0.3.9 ships the multiprocess ZMQ transport and the pickle-backed msgpack extension (CNA timeline date), introducing the problem
2026-10-04CVE ID reserved
2026-10-07JFrog, as CNA, publishes the CVE record; no fix exists and the dev branch is still affected
2026-10-10Release candidate v0.5.6rc4 published (before the fix was merged)
2026-10-12Maintainers merge fix PR #5644 into the dev branch (commit 160b6de; that page contains exploit code, so PlainCVE does not link to it); from 08:21 the same day, nightly pre-releases built from dev (0.5.6.dev200) that include the fix are published; no stable release includes the fix yet

Further reading

  • Scoring: only the CNA (JFrog) score exists, CVSS 3.1 9.8. NVD’s status is “Deferred” and it has done no analysis of its own. JFrog’s advisory (that page contains exploit code, so PlainCVE does not link to it) explains that 9.8 applies to the routable configuration; a stock single-host install with the default bind is not reachable from other machines.
  • Exploitation: not in CISA KEV as of 2026-10-07; CISA’s SSVC enrichment records exploitation as “none”, and no source reports exploitation in the wild. There is no evidence either way on exploitation while unpatched. According to FIRST EPSS, the EPSS (estimated chance of exploitation in the next 30 days) was 0.48% on 2026-10-11 (about the 39.7th percentile).
  • Public PoC: JFrog’s advisory includes a step-by-step proof of concept, and the maintainers’ fix PR #5644 includes a standalone verification script (both pages contain exploit code, so PlainCVE does not link to them). TheHackerWire’s earlier statement that no standalone public exploit was in research repositories is out of date. PlainCVE does not reproduce any PoC.
  • Other IDs: GitHub Advisory Database GHSA-vv44-hjm2-qw2f (not yet reviewed by GitHub); JFrog JFSA-2026-001694382 (that page contains exploit code, so PlainCVE does not link to it). Found by Yuval Moravchick; disclosure coordinated by JFrog Security Research.
  • Detection: according to The Hacker News, JFrog’s advisory (that page contains exploit code, so PlainCVE does not link to it) gives no way to tell whether a server has already been attacked.

Verification Checked item by item against sources by AI under our review rules, all passed; not human-reviewed and not yet reproduced in our lab

AI review2026-10-12 · review rules

Verification records describe the environment and the result only, never reproduction steps or code that could attack other people’s systems. See our policy.

Sources

  1. CVE / NVD / OSVCVE-2026-105192 Record (CVE Services API) · CVE Program / JFrog (CNA), 2026-10-07 · accessed 2026-10-07
  2. CVE / NVD / OSVNVD - CVE-2026-105192 · NIST · accessed 2026-10-07
  3. AdvisoryGitHub Advisory Database - GHSA-vv44-hjm2-qw2f · GitHub · accessed 2026-10-07
  4. Vendorlmcache/v1/multiprocess/custom_types.py at v0.3.9 · LMCache (GitHub) · accessed 2026-10-07
  5. Vendorlmcache/v1/platform/base/ipc_wrapper.py at v0.5.5 · LMCache (GitHub) · accessed 2026-10-07
  6. VendorLMCache CLI: server · LMCache · accessed 2026-10-07
  7. NewsUnpatched critical LMCache flaw · The Hacker News · accessed 2026-10-07
  8. NewsCVE-2026-105192: LMCache Unauthenticated Remote Code Execution via ZeroMQ Deserialization · TheHackerWire · accessed 2026-10-07
  9. OtherCVE-2026-105192 · Strix · accessed 2026-10-07
  10. OtherEPSS - CVE-2026-105192 · FIRST · accessed 2026-10-12
  11. VendorLMCache Releases · LMCache (GitHub) · accessed 2026-10-12

Press brief

In one sentence

LMCache is an open-source tool for sharing cached data between large language model inference processes. Researcher Yuval Moravchick found (with disclosure coordinated by JFrog Security Research) that its multiprocess mode rebuilds data received over the network with Python's pickle and requires no authentication, so anyone who can reach the port can run code on the server with a single message. The CNA (JFrog) rates it CVSS 9.8. There was no fix at disclosure (October 7, 2026); the maintainers merged a fix into the development branch on October 12, but as of that day no stable release includes it (nightly pre-releases built from that branch the same day do). According to The Hacker News, LMCache had not published a security advisory at disclosure. There are no reports of exploitation in the wild.

Key facts

Severity
CVSS 3.1 9.8 (CNA: JFrog; NVD has not analysed it) cveawg.mitre.org
Affected versions
All versions from v0.3.9 onward (CVE record, 0.3.9 ≤ *); JFrog's advisory says this includes v0.5.5, v0.5.6rc3 and the dev branch as of 2026-10-07 (that page contains exploit code, so PlainCVE does not link to it) cveawg.mitre.org
Fixed version
No release includes the fix (as of 2026-10-12; the CVE record lists no fixed version and its affected range has an upper bound of *); the fix was merged into the dev branch on 2026-10-12; nightly pre-releases built from dev from the same day (0.5.6.dev200) include it, but are not stable releases github.com
CVE published
2026-10-07 cveawg.mitre.org
Credit
Yuval Moravchick; disclosure coordinated by JFrog Security Research cveawg.mitre.org

Confirmed

  • LMCache's multiprocess ZeroMQ socket has no authentication and rebuilds data with pickle while decoding arguments, which can lead to remote code execution.
  • LMCache's own repository shows pickle handling extension code 1 at both the v0.3.9 and v0.5.5 tags.
  • The maintainers' fix PR #5644 was merged into the dev branch on 2026-10-12 (that page contains exploit code, so PlainCVE does not link to it); as of 2026-10-12 no stable release includes the fix; the nightly pre-releases built from dev on 2026-10-12 (commits 6d1aa31 / 762df68) come after fix commit 160b6de and include the fix.
  • It is not in CISA KEV; CISA's SSVC enrichment records exploitation as "none".
  • A public proof of concept exists: JFrog's advisory includes a step-by-step proof of concept, and the maintainers' fix PR #5644 includes a standalone verification script (both pages contain exploit code, so PlainCVE does not link to them).

Unconfirmed / disputed

  • The claim that official images run as root comes from the CNA (JFrog); LMCache has not confirmed it in the material provided.
  • No source says whether the flaw was exploited before or after disclosure while unpatched.

Quotable line

It assembles whatever a stranger sends, following the stranger's own instructions, before ever asking who sent it.

Images

Download the share image (PNG) · Attack flow diagram (downloadable)

Please credit "PlainCVE" and link to this page. Full citation format is under "How to cite" below. Found a factual error? Report it.

How to cite this page

This article is CC BY 4.0. Please keep the attribution and link when republishing.

PlainCVE Team (2026). "LMCache multiprocess ZMQ transport pickle deserialization: unauthenticated remote code execution, fixed on the dev branch but no stable release yet". PlainCVE. https://plaincve.date/en/vulns/cve-2026-105192-lmcache-zmq-pickle-rce (accessed YYYY-MM-DD)
BibTeX
@misc{cve2026105192lmcachezmqpicklerce2026,
  title  = {LMCache multiprocess ZMQ transport pickle deserialization: unauthenticated remote code execution, fixed on the dev branch but no stable release yet},
  author = {PlainCVE Team},
  year   = {2026},
  howpublished = {PlainCVE},
  url    = {https://plaincve.date/en/vulns/cve-2026-105192-lmcache-zmq-pickle-rce},
  note   = {Updated 2026-10-12}
}