LMDeploy RPC Server: Critical Unauthenticated RCE via Pickle Deserialization (CVE-2025-59953)

What happened

A GitHub Security Advisory (GHSA-5h8j-6crg-7rmw, tracked as CVE-2025-59953) discloses a critical remote code execution vulnerability in InternLM's lmdeploy, a popular LLM deployment/serving toolkit. The flaw lives in AsyncRPCServer.call_and_response() in zmq_rpc.py, which deserializes incoming ZMQ RPC messages with pickle.loads() without any validation or sanitization.

According to the maintainer's own assessment, the vulnerable RPC implementation shipped starting in lmdeploy 0.9.1. Prior to 0.10.2, the RPC server bound to tcp://* — i.e., all network interfaces — with no authentication and a randomized (but scannable) port. Any network peer able to reach that port could submit a crafted pickle payload and achieve arbitrary code execution on the host running the server. A public proof-of-concept demonstrates obtaining a reverse shell this way. Version 0.10.2 changes the bind address to localhost, closing the remote network attack surface, though the maintainers note the RPC protocol still relies on pickle internally and the loopback endpoint must remain isolated from untrusted local processes.

Why it matters for defenders

This is a CVSS 9.8, unauthenticated, network-reachable RCE in infrastructure commonly used to serve large language models — often on GPU hosts that are valuable targets and may sit inside less-monitored ML/data-science network segments. Because the vulnerable versions bind to all interfaces by default, any environment that exposed lmdeploy's RPC port to a shared network, VPC, or the internet — intentionally or not — should be treated as potentially exposed. A public PoC already exists, which historically shortens the window before opportunistic scanning and exploitation begin.

What defenders should do now

• Inventory hosts running lmdeploy and identify the installed version; treat anything using the RPC server on 0.9.1 through pre-0.10.2 as exposed.
• Upgrade to lmdeploy 0.10.2 or later, which binds the RPC server to localhost by default.
• Even after upgrading, ensure the loopback RPC endpoint cannot be reached by untrusted local processes or containers sharing the host's network namespace.
• As a network-layer compensating control, firewall off lmdeploy's RPC ports from anything other than trusted management hosts, and avoid exposing GPU/ML serving nodes directly to shared or public networks.
• Hunt for anomalous outbound connections or shell spawning (e.g., bash -i reverse shells) originating from processes associated with lmdeploy or ML serving workloads — a classic post-exploitation pattern for pickle deserialization RCE.
• Where feasible, monitor for unexpected pickle-formatted traffic on non-standard, randomized high ports, particularly from external or unfamiliar source IPs.

Developing intel

This item was published today and reflects the GHSA advisory and maintainer assessment as currently available; details such as broader in-the-wild exploitation or additional affected configurations may evolve. For the full technical writeup, PoC details, and maintainer guidance, see the original advisory: GHSA-5h8j-6crg-7rmw.