CVE-2025-66455: 
Python vulnerability analysis and mitigation

CVE-2025-66455 is a critical unauthenticated remote code execution vulnerability in LMDeploy's PyTorch DistServe/PD-disaggregation control plane, caused by unsafe Python pickle deserialization over ZeroMQ. It affects LMDeploy versions >= 0.9.2 and < 0.16.0 (pip package). The vulnerability was published on September 16, 2026, and patched in LMDeploy 0.16.0 released shortly after. It carries a CVSS v3.1 base score of 9.8 (Critical) (Github Advisory, InternLM Advisory).

The root cause is CWE-502 (Deserialization of Untrusted Data): the EngineP2PConnection.handle_zmq_recv() function in lmdeploy/pytorch/disagg/conn/engine_conn.py called recv_pyobj() on a ZeroMQ PULL socket, which internally uses pickle.loads() on peer-supplied bytes. An attacker can trigger this by sending an HTTP POST request to the unauthenticated /distserve/p2p_connect endpoint, supplying an attacker-controlled ZeroMQ address in the DistServeConnectionRequest.remote_engine_endpoint_info.zmq_address field. The LMDeploy engine then connects its PULL socket to that address, and when the attacker's ZeroMQ endpoint sends a crafted pickle payload, arbitrary Python code executes during deserialization — before any type or schema validation can occur. This vulnerability was introduced in commit b0b705f7 and only affects deployments using the PyTorch backend with PD-disaggregation/DistServe enabled (Github Advisory, Fix Commit).

Successful exploitation grants arbitrary code execution with the privileges of the LMDeploy serving process, which can expose sensitive assets including LLM model weights, user prompts, credentials, attached storage, cluster-network services, and host or GPU resources. An attacker may also modify or terminate the serving process entirely, impacting availability. Because API-key authentication is disabled by default, any network-reachable DistServe deployment is vulnerable without additional configuration, and compromise of the serving node could facilitate lateral movement within the cluster network (InternLM Advisory).

No public proof-of-concept exploit code has been observed, and there is no evidence of in-the-wild exploitation at the time of disclosure (Github Advisory). The EPSS score is 0.0, reflecting low current exploitation probability. The vulnerability is not listed in the CISA KEV catalog. However, the attack requires no authentication, no privileges, and no user interaction, making it trivially exploitable by any attacker with network access to the DistServe HTTP endpoint — a significant risk for publicly exposed deployments.

1. Reconnaissance: Identify internet-facing or cluster-accessible LMDeploy DistServe API servers running versions >= 0.9.2 and < 0.16.0 with the PyTorch backend and PD-disaggregation/DistServe enabled. Scan for the HTTP API port and probe for the /distserve/p2p_connect endpoint.
2. Set up malicious ZeroMQ endpoint: On an attacker-controlled host, start a ZeroMQ PUSH socket bound to a reachable address (e.g., tcp://attacker-ip:5555) that will serve a crafted pickle payload.
3. Craft pickle payload: Generate a malicious Python pickle object that executes arbitrary code upon deserialization (e.g., using pickle.dumps with a custom __reduce__ method to spawn a reverse shell or execute a command).
4. Trigger the connection: Send an unauthenticated HTTP POST request to POST /distserve/p2p_connect on the target server, with a JSON body containing remote_engine_endpoint_info.zmq_address set to the attacker's ZeroMQ endpoint address.
5. Deliver pickle payload: Once the target's ZeroMQ PULL socket connects to the attacker's endpoint, send the crafted pickle payload via the PUSH socket.
6. Achieve code execution: The target's handle_zmq_recv() calls recv_pyobj(), which invokes pickle.loads() on the attacker's payload, executing arbitrary code as the LMDeploy serving process (InternLM Advisory, Fix Commit).

• Network: Unexpected outbound ZeroMQ connections (TCP) from the LMDeploy serving node to external or untrusted IP addresses on arbitrary ports; unusual inbound HTTP POST requests to /distserve/p2p_connect from untrusted sources.
• Logs: HTTP access logs showing POST requests to /distserve/p2p_connect with unfamiliar or external zmq_address values; LMDeploy application logs showing ZeroMQ connection events to unexpected endpoints; error messages referencing handle_zmq_recv or recv_pyobj.
• Process: Unexpected child processes spawned by the LMDeploy Python process (e.g., bash, sh, curl, wget, python, nc); unusual GPU or CPU resource consumption indicative of injected workloads.
• File System: New or modified files in the LMDeploy installation directory or model storage paths; unexpected cron jobs, systemd units, or scripts created by the serving process account.

Upgrade to LMDeploy 0.16.0 or later, which replaces the unsafe recv_pyobj()/send_pyobj() pickle-based ZeroMQ protocol with recv_json()/send_json() and validates received objects against the DistServeCacheFreeRequest Pydantic schema before use (LMDeploy v0.16.0, Fix Commit). For operators unable to upgrade immediately, the following workarounds should be applied in combination: (1) block untrusted clients from reaching /distserve/* HTTP endpoints via firewall or reverse proxy ACLs; (2) restrict both the DistServe HTTP and ZeroMQ control planes to trusted cluster-internal networks; (3) explicitly configure API-key authentication; and (4) block arbitrary outbound ZeroMQ connections from serving nodes. Note that these measures reduce exposure but do not eliminate the underlying pickle deserialization risk (InternLM Advisory).