GPU VulnDB

Database/AI/ML frameworks & serving

LMDeploy: unauthenticated pickle deserialization in the DistServe control plane gives RCE

CVSS 9.8CVE-2025-66455AI/ML frameworks & servingcurated

Impact

The PyTorch-backend DistServe control plane deserializes ZeroMQ messages with recv_pyobj(), which is pickle - and the peer address it connects to is supplied by anyone who can POST to /distserve/p2p_connect. API-key auth is off unless the operator turned it on, so on a typical deployment an unauthenticated caller makes the server dial an attacker-controlled ZeroMQ endpoint and gets arbitrary code execution as the serving process. That process holds the GPUs, the model weights on local disk, and whatever cluster credentials the serving pod was given, so this is a foothold on a GPU node rather than just a crashed inference server. Only deployments running the PyTorch backend with PD-disaggregation/DistServe enabled expose this path; ordinary single-process serving does not.

Who can reach it

Anyone with network reach to the DistServe API server's HTTP port. No authentication is required unless the operator explicitly configured API keys, and the attacker also needs the serving node to be able to make an outbound ZeroMQ connection back to them.

What to do

Upgrade to LMDeploy 0.16.0 and restart the serving processes - a rolling restart of the inference tier, no node reboot. Until then, keep untrusted clients off /distserve/*, bind the DistServe HTTP and ZeroMQ control planes to trusted cluster networks only, turn on API-key authentication, and block arbitrary outbound ZeroMQ from serving nodes. The vendor notes these reduce exposure but do not make pickle safe.

References

Related entries

All AI/ML frameworks & serving entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.