CVE-2025-59953 in LMDeploy
Summary
by MITRE • 09/16/2026
LMDeploy is a toolkit for compressing, deploying, and serving large language models. Starting in version 0.9.1 and prior to version 0.10.2, 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. Version 0.10.2 contains a patch.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/16/2026
The LMDeploy toolkit serves as a critical infrastructure component for compressing, deploying, and serving large language models within modern artificial intelligence workflows. A significant security flaw was identified in the remote procedure call mechanism implemented between version 0.9.1 and prior to version 0.10.2. The vulnerability resides specifically within the AsyncRPCServer class located in the zmq_rpc.py module, which facilitates inter-process communication for model inference requests. This server component is designed to accept incoming RPC messages from clients or other services within a distributed AI deployment architecture, making it an attractive target for attackers seeking to compromise the underlying system hosting the language models.
The core technical flaw involves improper deserialization of untrusted data. Within the call_and_response method, which handles the processing of received RPC payloads, the implementation directly invokes Python's pickle.loads function on incoming messages without performing any sanitization or validation checks. The Python pickle module is inherently insecure for handling untrusted input because its deserialize operation can execute arbitrary code during the reconstruction process. When an attacker crafts a maliciously formatted pickle payload containing exploit code, such as shell commands or reverse shells, and sends it to the vulnerable RPC endpoint, the server will automatically execute this code upon deserialization. This results in a remote code execution vulnerability that allows full control over the host system where LMDeploy is running.
From an industry standard perspective, this vulnerability maps directly to CWE-502, which describes Deserialization of Untrusted Data. The lack of input validation and the use of a dangerous deserialization library constitute a classic instance of this weakness. Furthermore, in terms of tactical classification within the MITRE ATT&CK framework, this flaw facilitates Initial Access through Exploitation for Remote Code Execution (T1210) and potentially Privilege Escalation if the service runs with elevated privileges. The attack vector is remote over the network protocol used by ZeroMQ, allowing an attacker to exploit the vulnerability without requiring prior authentication or local access, provided they can reach the RPC port exposed by the LMDeploy server.
The operational impact of this vulnerability is severe for organizations deploying large language models in production environments. Successful exploitation grants an adversary complete command and control over the inference server. This can lead to data exfiltration of sensitive training data or proprietary model weights, denial of service through resource exhaustion, or further lateral movement within the internal network where the AI services are hosted. Given that LLM deployments often involve significant computational resources and valuable intellectual property, compromising these systems poses a substantial risk to business continuity and data integrity.
To mitigate this vulnerability, organizations must upgrade their LMDeploy installations to version 0.10.2 or later, which contains the necessary patch to address the insecure deserialization issue. If upgrading is not immediately feasible, temporary mitigations include restricting network access to the RPC port using firewall rules so that only trusted internal services can communicate with it. Additionally, running the LMDeploy service under a restricted user account with minimal privileges can limit the potential damage of an exploitation attempt. It is also advisable to audit other components in the AI stack for similar deserialization practices and ensure that all third-party libraries are kept up to date to prevent exposure to known vulnerabilities.