CVE-2026-76850 in lmdeploy
Zusammenfassung
von VulDB • 20.08.2026
LMDeploy deserialisiert Nachrichten von Peers im disaggregierten Serving-Modus mit pickle. Die Coroutine handle_zmq_recv in lmdeploy/pytorch/disagg/conn/engine_conn.py liest peer-to-peer-Anfragen ohne Cache-Nutzung über recv_pyobj(), wodurch die empfangenen Bytes mit pickle.loads() deserialisiert werden, und der isinstance-Check gegen DistServeCacheFreeRequest erfolgt erst nach Abschluss der Deserialisierung. Der Peer, der diese Bytes bereitstellt, ist vom Aufrufer kontrollierbar: p2p_connect übergibt remote_engine_endpoint_info.zmq_address aus dem Anfragetext an connect() auf einem ZMQ PULL-Socket, und die Endpunkte POST /distserve/p2p_initialize und /distserve/p2p_connect in lmdeploy/serve/openai/api_server.py wenden keine Authentifizierung an, es sei denn, der Server wird mit api_keys gestartet, was standardmäßig None ist. Ein entfernter Angreifer kann eine Engine dazu bringen, von einem ZMQ-Endpunkt unter ihrer Kontrolle zu ziehen und beliebigen Code im Engine-Prozess auszuführen. Bereitstellungen, die das disaggregierte Serving nicht aktivieren, sind nicht betroffen, da der Empfangsloop erst gestartet wird, wenn das Migrations-Backend die Verbindung akzeptiert.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.