LMDeploy: unauthenticated p2p endpoints let a remote peer deliver a pickle payload for engine RCE

Impact

On a node running LMDeploy with disaggregated prefill/decode, the engine's receive loop reads peer messages with recv_pyobj(), which calls pickle.loads() before any type check. The POST /distserve/p2p_initialize and /distserve/p2p_connect endpoints apply no authentication unless the server was started with api_keys, which defaults to None, and the peer ZMQ address comes straight from the request body. An attacker who can reach the API port points the engine at a ZMQ endpoint they control and executes arbitrary code inside the engine process, which owns the GPUs, the loaded weights, and the KV cache of every request in flight on that node. Deployments that do not enable disaggregated serving are not affected, because the receive loop only starts once the migration backend accepts a connection.

Who can reach it

Anyone who can send HTTP to the LMDeploy API server. No authentication is required in the default configuration (api_keys=None), and the attacker also needs to be reachable by the engine's ZMQ PULL socket.

What to do

Apply the upstream fix in commit f05b4ad8bf2e2d84101a1d63b3c44fadd99223b2; the record names no fixed release. Until then, start the server with api_keys set and restrict the /distserve/* endpoints to the internal migration network with a firewall or network policy. Either path requires restarting the engine processes, which drops in-flight inference on those GPUs — roll replicas one at a time. No host or firmware maintenance is involved.

References