CVE-2026-105192: Critical LMCache Unauthenticated Remote Code Execution

Executive summary

A critical vulnerability tracked as CVE-2026-105192 affects the multiprocess mode of LMCache, an open-source caching layer used to accelerate large language model inference platforms such as vLLM. A remote attacker who can reach the affected ZeroMQ listener can execute code without authenticating to LMCache.

The vulnerable service decodes MessagePack requests received over ZeroMQ. One MessagePack extension handler passes attacker-controlled bytes to Python’s pickle.loads() function. Python pickle is unsafe for untrusted data because a serialized object can invoke functions during reconstruction. The ZeroMQ transport does not authenticate clients, so a single crafted message can execute code with the privileges of the LMCache process before the operation handler validates the request.

JFrog disclosed the vulnerability and a functional proof of concept on October 7, 2026. JFrog assigned a CVSS 3.1 score of 9.8. The affected range begins with LMCache 0.3.9. The latest stable PyPI release, 0.5.5, and the 0.5.6rc4 release candidate remain affected.

LMCache maintainers merged a source-level fix on October 12, 2026. The fix replaces pickle-based device descriptors with typed and validated MessagePack structures. No patched stable release was available at the research cutoff, so organizations should not assume that installing the latest stable package resolves the issue.

The vulnerability is most serious when administrators configure the multiprocess service to listen on a routable address. A standard single-host deployment binds the service to localhost, which limits remote reachability. Multi-node deployments commonly require a routable listener, however, and LMCache’s version 0.5.5 Kubernetes example explicitly listens on 0.0.0.0 while using the host network.

[!IMPORTANT] Organizations should restrict the multiprocess listener to trusted systems immediately and plan a coordinated upgrade to an official release containing the October 12 security fix. Network isolation is a compensating control, not a repair for unsafe deserialization.

Vulnerability identity and status

Field	Assessment
CVE	CVE-2026-105192
CVE status	Published
Affected product	LMCache
Affected feature	Multiprocess mode using the ZeroMQ request transport
Vulnerability classes	CWE-502 and CWE-306
CVSS	9.8 Critical, CVSS 3.1
Public disclosure date	October 7, 2026
Exploit status	Functional public proof of concept reported
Observed exploitation	No authoritative evidence identified
Source fix	Merged on October 12, 2026
Patched stable release	None identified at the research cutoff
CISA KEV	Not listed at the research cutoff

The CVE Program record maps the issue to:

CWE-502, Deserialization of Untrusted Data
CWE-306, Missing Authentication for Critical Function

These weaknesses combine to turn a dangerous local object format into an unauthenticated network code-execution path.

What LMCache is

LMCache stores and reuses key-value cache data generated during LLM inference. Reusing this data can reduce repeated computation and improve response latency.

In an in-process configuration, LMCache runs inside the vLLM worker and does not open the vulnerable multiprocess port. In multiprocess mode, LMCache runs as a standalone service that can serve multiple inference workers. Workers communicate with the service through a configurable request transport, including ZeroMQ or gRPC.

This architecture creates a network trust boundary. Data crossing that boundary must be authenticated and decoded using a format that cannot instantiate executable objects. CVE-2026-105192 violates both requirements in the affected ZeroMQ path.

Technical analysis

Vulnerable data path

The multiprocess service opens a ZeroMQ ROUTER socket. Worker processes use DEALER sockets to submit operations encoded as MessagePack objects.

LMCache registers MessagePack extension type 1 for device interprocess communication wrappers. In affected versions, DeviceIPCWrapper.Deserialize passes the extension body to pickle.loads().

The attack path is:

LMCache starts in multiprocess mode with its ZeroMQ port reachable over the network.
A remote client connects to the unauthenticated transport.
The client submits a MessagePack request containing extension type 1.
The extension body contains an attacker-controlled Python pickle object.
LMCache invokes pickle.loads() while decoding the request.
The object performs attacker-controlled behavior as the LMCache process user.
Any later request-type or argument validation occurs after code execution.

The attacker does not need to submit a semantically valid LMCache operation. Deserialization happens before the intended operation handler can reject the request.

Why pickle is unsafe for network data

Python pickle preserves complex object identity and behavior. Reconstructing a pickled object can invoke callable objects selected by the serialized input. This is expected pickle behavior rather than an accidental parser edge case.

Authentication could reduce who is allowed to submit messages, but it would not make arbitrary pickle deserialization intrinsically safe. The durable fix is to use constrained data structures, validate every field, and select local implementations from an explicit allowlist.

Missing transport authentication

JFrog reports that the affected ZeroMQ socket does not use CURVE, ZAP, password, or message authentication. Any host that can establish a connection can submit data to the decoder.

This missing authentication explains why a dangerous deserialization primitive becomes unauthenticated remote code execution. Firewall rules can narrow the set of potential attackers, but every permitted peer can still reach the vulnerable path.

Exposure conditions

A deployment must meet these conditions for network exploitation:

LMCache is running in multiprocess mode.
The ZeroMQ request transport is enabled.
The deployed build still uses pickle for device-wrapper decoding.
The attacker can connect to the multiprocess listener.

Lower-exposure configurations

Risk is materially lower when:

LMCache runs only inside a vLLM worker process.
Multiprocess mode is disabled.
The ZeroMQ service remains bound to localhost.
Network controls prevent untrusted systems from reaching the listener.

These conditions reduce reachability. They do not remove the vulnerable code.

Higher-exposure configurations

Risk is highest when:

The service uses --host 0.0.0.0 or another routable address.
Kubernetes exposes the workload through host networking, a Service, a load balancer, or a permissive network policy.
Multi-node inference workers share the cache over an insufficiently trusted network.
The process runs as root or receives broad Kubernetes permissions.
The LMCache workload can access model artifacts, credentials, internal APIs, or adjacent inference services.

The LMCache version 0.5.5 DaemonSet example combines hostNetwork: true with --host 0.0.0.0. The example uses port 6555, while JFrog describes 5555 as the default. Defenders should inventory configured ports rather than search for a single port number.

Affected versions

Version or branch	Status as of October 12, 2026	Evidence assessment
Earlier than 0.3.9	Not established as affected	Vulnerable path reportedly shipped in 0.3.9
0.3.9 through 0.5.5	Affected	CVE record, advisory, and inspected source
0.5.6rc1 through 0.5.6rc3	Affected	JFrog advisory
0.5.6rc4 and 0.5.6rc4.dev27	Affected	Published before the fix; pickle remains present
Development branch before commit `160b6dec...`	Affected	Maintainer source history
Development branch from commit `160b6dec...`	Device-wrapper path fixed	Maintainer security commit
October 12 nightly artifacts	Unknown	Artifact provenance not independently validated
Future stable release	Unknown	No patched stable release available

The published CVE record represents the affected range as version 0.3.9 and later without an upper boundary. That description was accurate when the record was published on October 7. It had not yet been updated to reflect the source-level fix merged on October 12.

Severity and impact

JFrog assigned:

CVSS 3.1: 9.8 Critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

CVSS property	Assessment
Attack vector	Network
Attack complexity	Low
Privileges required	None
User interaction	None
Scope	Unchanged
Confidentiality	High
Integrity	High
Availability	High

The 9.8 score applies to a configuration where the affected listener is network reachable. A localhost-only deployment is not remotely reachable from another host without an additional access path.

Demonstrated impact

JFrog reports successful arbitrary command execution through one unauthenticated ZeroMQ message. The executed code inherits the user, filesystem access, environment, network access, and security context of the LMCache process.

JFrog also reports that official LMCache container images run the process as root. That claim was not independently reproduced for this report. Organizations should inspect the user configured in the exact image and Kubernetes security context they deploy.

Plausible follow-on impact

Depending on process privileges and network placement, a successful attacker could:

Read or modify data available to the LMCache process.
Tamper with cached inference state.
Steal accessible service credentials or model artifacts.
Disrupt LLM inference workloads.
Pivot to adjacent inference or cluster services.
Establish persistence in writable volumes.
Attempt container escape through separate runtime or configuration flaws.

These are plausible consequences of process-level code execution. They were not all demonstrated in the public disclosure. Root inside a container also does not automatically grant root access to the Kubernetes node.

Exploitation status

The evidence supports this classification:

Functional public exploit reported; no observed exploitation established.

JFrog published working proof-of-concept details and reports successful command execution. This is stronger evidence than a theoretical exploit claim.

At the research cutoff:

NVD included CISA SSVC enrichment with exploitation: none, timestamped October 7, 2026.
CVE-2026-105192 was absent from the CISA Known Exploited Vulnerabilities catalog.
No authoritative report of exploitation in the wild was identified.

Absence from CISA KEV does not prove that exploitation has not occurred. It means the available sources do not establish observed exploitation that meets CISA’s inclusion criteria.

Patch status

The original Hacker News article described the vulnerability as unpatched. That was accurate when JFrog disclosed the issue on October 7.

On October 12, LMCache merged commit 160b6dec469edb765efd1fad42aca5a438b08bb5, titled [Security][MP] Remove pickle from device IPC descriptors (CVE-2026-105192).

The change:

Removes pickle.dumps() and pickle.loads() from the device IPC wrapper.
Introduces typed and versioned MessagePack descriptors.
Uses an explicit allowlist to map descriptor tags to local implementations.
Rejects unknown fields and unsupported descriptor types.
Rejects legacy pickle payloads without falling back to pickle.
Adds tests for malformed, unknown, and legacy payloads.

The patch appears to address the unsafe device-wrapper deserialization path described in CVE-2026-105192. Its documentation also identifies important limits:

It does not add RPC authentication.
It does not replace every pickle-based payload elsewhere in the multiprocess architecture.
It requires compatible client and server upgrades because legacy descriptors are rejected.

The accurate status at the research cutoff is:

Fixed in development source, but no patched stable release was available.

PyPI still identified LMCache 0.5.5 as the latest stable version. The 0.5.6rc4 source still contained the vulnerable pickle path. A nightly release was published after the patch merged, but this report did not validate its artifact provenance or production suitability.

Recommended actions

Immediate containment

Inventory Python packages, containers, and Kubernetes workloads that include LMCache.
Determine whether each deployment uses multiprocess mode and the ZeroMQ request transport.
Review process arguments, manifests, Services, host networking, network policies, security groups, and firewall rules for routable listeners.
Bind the service to localhost when cross-host access is unnecessary.
Restrict required cross-host access to explicitly authorized inference workers.
Remove public load balancers, public node ports, and unrestricted ingress.
Run LMCache as a non-root user and remove unnecessary capabilities and sensitive mounts.
Plan a coordinated client and server upgrade because the fixed wire format rejects legacy pickle descriptors.

Remediation

Deploy an official LMCache release that contains commit 160b6dec469edb765efd1fad42aca5a438b08bb5 or a documented successor fix.

Before deployment, verify that the artifact:

Does not invoke pickle from DeviceIPCWrapper.Deserialize.
Uses typed MessagePack device descriptors.
Rejects legacy pickle payloads.
Includes IPC wire-format validation tests.
Is compatible with every participating worker and server.

Avoid treating an unverified nightly artifact as a production fix unless the organization accepts its support and stability risks.

Architectural hardening

After upgrading:

Add mutually authenticated transport security.
Authorize individual clients or workload identities.
Reject routable binds when authentication is not configured.
Apply strict type, field, and size limits to every decoded message.
Review remaining pickle use that can receive network or cross-process data.
Separate cache services by trust domain or tenant where isolation is required.

Detection and hunting opportunities

JFrog did not publish a definitive compromise indicator. The following ideas are untested hypotheses and require validation against representative telemetry.

Network telemetry

Review:

Connections to LMCache multiprocess ports from unexpected hosts.
Traffic to 5555, 6555, and environment-specific LMCache ports.
Internet-originated or cross-namespace connections to LMCache workloads.
New systems communicating with the ZeroMQ listener.
Malformed request bursts followed by connection termination.

Port-only detection is insufficient because operators can configure arbitrary ports.

Host and container telemetry

Investigate:

Child processes launched by the LMCache Python process.
Shells, download tools, package managers, or administrative utilities started from the LMCache container.
Unexpected file creation in temporary, application, or mounted directories.
New outbound connections from LMCache workloads.
Credential or service-account access inconsistent with cache operation.
Changes to Python modules, startup files, or writable volumes.
Container restarts or errors following unusual ZeroMQ traffic.

A malicious pickle does not need to create a child process. It can perform actions inside the Python process, so process-creation monitoring alone cannot exclude compromise.

Application telemetry

Look for:

MessagePack extension decode failures.
REGISTER_KV_CACHE type or argument errors.
Exceptions immediately after a new worker connection.
Unknown worker identifiers.
Requests from addresses outside the approved inference-worker set.

These signals require validation against the deployed LMCache version and logging configuration.

Incident response guidance

If a vulnerable listener was reachable by an untrusted network, upgrading alone does not establish that the environment is clean.

Isolate the affected workload.
Preserve container, node, application, and network telemetry.
Record the package version, image digest, process command line, and configuration.
Rotate credentials and tokens accessible to the LMCache process.
Review mounted volumes and model repositories.
Inspect adjacent inference workers and cluster services for lateral movement.
Redeploy from trusted images rather than attempting in-place cleanup.
Confirm that the replacement artifact contains the source fix.
Restore network access only after applying authentication or strict segmentation.

Several additional LMCache issues were reported around October 6, including allegations of unauthenticated cache access and unauthenticated management services. They should not be treated as confirmed extensions of CVE-2026-105192 because:

They affect different components and security properties.
Maintainer confirmation and CVE assignments were not established.
Some default behaviors may differ in later release candidates.

These findings warrant separate investigation. Combining them with this CVE would overstate the available evidence.

A related vLLM denial-of-service issue, CVE-2026-105756, is also distinct. It reportedly affects malformed cache_salt handling and was fixed in vLLM 0.30.0. It does not provide remote code execution.

Timeline

Date	Event
October 2025	LMCache 0.3.9 reportedly introduces the vulnerable decode path
October 4, 2026	CVE-2026-105192 is reserved
October 7, 2026	JFrog publishes the CVE and functional proof of concept
October 7, 2026	CVE record is published with a CVSS 3.1 score of 9.8
October 10, 2026	LMCache 0.5.6rc4 artifacts are published with the pickle path present
October 12, 2026, 06:22 UTC	LMCache merges source fix commit `160b6dec...`
October 12, 2026, 08:42 UTC	A new nightly is published; fix inclusion is not validated here
October 12, 2026, 09:24 UTC	Research cutoff; PyPI still lists 0.5.5 as latest stable

Key takeaways

CVE-2026-105192 is a technically demonstrated unauthenticated remote code-execution vulnerability.
Exploitation requires access to the LMCache multiprocess ZeroMQ listener.
Localhost-only and in-process deployments have materially lower exposure.
Routable multi-node deployments are the primary concern.
The authoritative CVSS 3.1 score is 9.8 for a network-reachable deployment.
A functional public proof of concept exists.
No observed exploitation was established at the research cutoff.
A source-level fix merged on October 12, 2026.
LMCache 0.5.5 and 0.5.6rc4 remain affected.
No patched stable PyPI release was available at the research cutoff.
Network isolation should be applied while organizations prepare a verified, coordinated upgrade.

References

Sources were accessed on October 12, 2026.

Report metadata

Field	Value
Report version	1.0
Report date	October 12, 2026
Research cutoff	October 12, 2026, 09:24 UTC
Classification	Public
Validation	Public-source research only