LMDeploy DistServe RCE via Pickle Deserialization in P2P Connection Handler (CVE-2025-66455)

A newly disclosed advisory (GHSA-2vh9-42vm-xmv2, CVE-2025-66455, CVSS 9.8) affects LMDeploy, a popular LLM serving framework, when its PyTorch backend is run with PD-disaggregation ("DistServe") enabled. According to the advisory, the POST /distserve/p2p_connect endpoint accepts an attacker-supplied ZeroMQ address that the server's control-plane connects to. The receiving code, EngineP2PConnection.handle_zmq_recv() in lmdeploy/pytorch/disagg/conn/engine_conn.py, used PyZMQ's recv_pyobj(), which deserializes incoming data with Python's pickle module — a well-known arbitrary-code-execution primitive. Because arbitrary code runs during deserialization itself, any post-receipt type checking is reported to be ineffective as a mitigation.

Why It Matters

The advisory states that API-key authentication is not enabled by default. Where DistServe is exposed without an API key, this reportedly allows unauthenticated remote code execution with the privileges of the LMDeploy serving process. Given LMDeploy's use in production LLM inference pipelines, successful exploitation could expose model weights, prompts, credentials, attached storage, and other cluster resources, or allow an attacker to disrupt or hijack the serving process. A public PoC is noted as available for this issue, which raises the urgency for affected operators. Standard LMDeploy deployments that do not use PD-disaggregation are reported as not exposed to this specific data flow.

Affected Versions

• lmdeploy >= 0.9.2, < 0.16.0, when the PyTorch backend with PD-disaggregation/DistServe is enabled
• Fixed in LMDeploy 0.16.0, which replaces the pickle-based protocol with JSON serialization and Pydantic schema validation

What Defenders Should Do Now

• Inventory any LLM-serving infrastructure running LMDeploy with PD-disaggregation/DistServe enabled and prioritize upgrading to 0.16.0 or later.
• Until upgraded, restrict network access to /distserve/* HTTP endpoints and the associated ZeroMQ control-plane ports to trusted, internal cluster networks only.
• Enable API-key authentication on the DistServe API server if it is not already configured.
• Block or tightly control arbitrary outbound ZeroMQ connections from serving nodes, since exploitation relies on the server connecting out to an attacker-controlled endpoint.
• For hunting, review logs and network flow data for unexpected outbound ZeroMQ connections initiated by LMDeploy processes, or unusual `p2p_connect` requests to the DistServe API, as a potential indicator of exploitation attempts.
• Treat these network controls as compensating measures only — per the advisory, they reduce exposure but do not make the underlying pickle deserialization safe.

Developing Intel

This is net-new intelligence from a same-day GHSA advisory; details may evolve as the community and vendor provide further guidance. Full technical details, the fix commit, and workaround guidance are available in InternLM's original advisory: GHSA-2vh9-42vm-xmv2.