CVE-2026-76850: LMDeploy Pickle Deserialization RCE Flaw

CVE-2026-76850 is a remote code execution vulnerability in LMDeploy caused by unsafe pickle deserialization in disaggregated-serving peer messages. Attackers can execute arbitrary code by directing engines to malicious ZMQ endpoints. This article covers technical details, affected versions, impact, and mitigation strategies.

CVE-2026-76850 Overview

CVE-2026-76850 is an insecure deserialization vulnerability [CWE-502] in LMDeploy, an inference and serving toolkit for large language models developed by InternLM. The flaw resides in the disaggregated-serving peer connector, where the handle_zmq_recv coroutine calls recv_pyobj() on attacker-influenced ZeroMQ (ZMQ) traffic. That call invokes pickle.loads() on caller-controlled bytes before any type validation runs. A remote unauthenticated attacker can direct an engine to pull from a ZMQ endpoint under their control and achieve arbitrary code execution in the engine process.

Critical Impact
Remote unauthenticated attackers can execute arbitrary code in the LMDeploy engine process when disaggregated serving is enabled and api_keys is not configured.

Affected Products

InternLM LMDeploy versions prior to v0.16.0 (vulnerable code present in v0.15.0)
LMDeploy deployments running with disaggregated serving enabled
LMDeploy servers started without the api_keys option configured

Discovery Timeline

2026-08-19 - CVE-2026-76850 published to NVD
2026-08-20 - Last updated in NVD database

Technical Details for CVE-2026-76850

Vulnerability Analysis

The vulnerability is an unsafe deserialization primitive exposed through LMDeploy's peer-to-peer cache-free request path. The handle_zmq_recv coroutine in lmdeploy/pytorch/disagg/conn/engine_conn.py receives bytes on a ZMQ PULL socket using recv_pyobj(), which internally invokes pickle.loads() on the payload. The isinstance check against DistServeCacheFreeRequest runs after deserialization has already completed, so a malicious pickle stream executes its __reduce__ payload before any validation occurs.

Authentication is missing on the initiating endpoints. The POST /distserve/p2p_initialize and /distserve/p2p_connect handlers in lmdeploy/serve/openai/api_server.py apply no authentication unless the server is launched with api_keys, which defaults to None. Deployments that do not enable disaggregated serving are unaffected, because the receive loop only starts once the migration backend accepts a peer connection.

Root Cause

The root cause is the use of Python's pickle module as the wire format for cross-process peer requests. pickle.loads() is unsafe on untrusted input by design, and the peer endpoint is caller-controlled. p2p_connect passes remote_engine_endpoint_info.zmq_address from the request body directly into connect() on the ZMQ PULL socket.

Attack Vector

An attacker sends a POST /distserve/p2p_initialize and /distserve/p2p_connect request to the LMDeploy HTTP API, supplying a zmq_address that points to a ZMQ endpoint under their control. The engine connects to the attacker's endpoint and enters the receive loop. The attacker then pushes a crafted pickle payload, which is deserialized inside the engine process and executes arbitrary code in the LMDeploy runtime context.

python

# Security patch: switch from pickle to JSON for P2P ZMQ requests
import zmq
import zmq.asyncio
from pydantic import ValidationError

from lmdeploy.logger import get_logger
from lmdeploy.pytorch.disagg.conn.protocol import (
    # ...
)

Source: GitHub Commit f05b4ad - the fix replaces recv_pyobj()/pickle with JSON parsing validated by a Pydantic model, eliminating the deserialization primitive.

Detection Methods for CVE-2026-76850

Indicators of Compromise

Inbound HTTP requests to /distserve/p2p_initialize or /distserve/p2p_connect from unexpected source addresses.
Outbound ZMQ connections from LMDeploy engine hosts to unfamiliar external endpoints specified via zmq_address.
Child processes spawned by the LMDeploy engine, such as shells, network utilities, or interpreters that do not appear in a clean baseline.

Detection Strategies

Monitor for LMDeploy processes performing execve of shells or arbitrary binaries shortly after a p2p_connect API call.
Alert on any LMDeploy server exposing /distserve/* endpoints without api_keys configured.
Inspect ZMQ socket connections initiated by the engine and flag destinations outside the approved peer inventory.

Monitoring Recommendations

Enable network flow logging for hosts running LMDeploy and correlate outbound ZMQ traffic with prior HTTP p2p_* requests.
Ingest LMDeploy application logs into a SIEM or data lake and hunt for anomalous peer registration events.
Track version metadata on inference servers and alert when versions prior to v0.16.0 reappear in production.

How to Mitigate CVE-2026-76850

Immediate Actions Required

Upgrade LMDeploy to v0.16.0 or later, which replaces pickle transport with JSON validated by Pydantic.
If upgrade is not immediately possible, disable disaggregated serving so the vulnerable receive loop is never started.
Restrict network exposure of the LMDeploy HTTP API to trusted management networks only.

Patch Information

The fix is delivered in GitHub Release v0.16.0 via commit f05b4ad, tracked in GitHub Issue #4804. See the VulnCheck Advisory on lmdeploy for additional analysis.

Workarounds

Start the LMDeploy server with the api_keys option set to a strong secret so that /distserve/p2p_initialize and /distserve/p2p_connect require authentication.
Place the LMDeploy API behind a reverse proxy that enforces mutual TLS or an authenticated ingress controller.
Apply egress firewall rules to prevent engine hosts from initiating ZMQ connections to untrusted destinations.

bash

# Launch LMDeploy with API key authentication to gate p2p endpoints
lmdeploy serve api_server \
  --server-name 0.0.0.0 \
  --server-port 23333 \
  --api-keys "$(openssl rand -hex 32)" \
  /path/to/model