CVE-2026-76850: LMDeploy Remote Code Execution via Unsafe Pickle Deserialization in the Disaggregated Serving Peer Connector
LMDeploy deserializes disaggregated-serving peer messages with pickle. The handlezmqrecv coroutine in lmdeploy/pytorch/disagg/conn/engineconn.py reads peer-to-peer cache-free requests with recvpyobj(), which deserializes the received bytes with pickle.loads(), and the isinstance check against DistServeCacheFreeRequest runs only after deserialization has already completed. The peer that supplies those bytes is caller-controlled: p2pconnect passes remoteengineendpointinfo.zmqaddress from the request body to connect() on the ZMQ PULL socket, and the POST /distserve/p2pinitialize and /distserve/p2pconnect endpoints in lmdeploy/serve/openai/apiserver.py apply no authentication unless the server is started with apikeys, which defaults to None. A remote attacker can direct an engine to pull from a ZMQ endpoint under their control and execute arbitrary code in the engine process. Deployments that do not enable disaggregated serving are not affected, because the receive loop is only started once the migration backend accepts the connection.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Start lmdeploy/serve/openai with api_keys enabled so that the /distserve/p2p_initialize and /distserve/p2p_connect endpoints require authentication instead of defaulting to None.
lmdeploy/serve/openai/api_server.py (HTTP endpoints: /distserve/p2p_initialize, /distserve/p2p_connect) api_keys = set to non-None (required) - Compensating control
Disable disaggregated serving (ensure disaggregated serving is not enabled), since deployments that do not enable disaggregated serving are stated as not affected.
Event History
Frequently Asked Questions
Which deployments are exposed?
Only deployments with disaggregated serving enabled are affected. The vulnerable receive loop starts only after the migration backend accepts a connection; deployments that do not enable disaggregated serving are not affected.
Does exploitation require authentication or prior access?
By default, no. The p2p initialization and connection endpoints have no authentication unless the server is started with api_keys, whose default is None; an unauthenticated remote attacker can supply a ZMQ endpoint they control.
What access does successful exploitation provide?
An attacker can execute arbitrary code in the engine process. They do this by directing the engine to pull a malicious peer message that is deserialized with pickle before its type is checked.
What mitigation is available if patching cannot happen immediately?
Disable disaggregated serving to prevent the vulnerable receive loop from starting. Starting the server with api_keys also avoids the default unauthenticated exposure of the relevant API endpoints.