CVE-2025-66455: LMDeploy — CRITICAL

Q: Is CVE-2025-66455 actively exploited?

No confirmed active exploitation of CVE-2025-66455 has been reported, but organizations should still patch proactively.

Q: How to fix CVE-2025-66455?

Update to patched version: LMDeploy 0.16.0.

Q: What is the CVSS score for CVE-2025-66455?

CVE-2025-66455 has a CVSS v3.1 base score of 9.8 (CRITICAL).

LMDeploy is a toolkit for compressing, deploying, and serving large language models. Starting in version 0.9.2 and prior to version 0.16.0, LMDeploy's PyTorch DistServe/PD-disaggregation control plane used `recv_pyobj()` to deserialize messages received through a ZeroMQ PULL socket. PyZMQ...

Full CISO analysis pending enrichment.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
LMDeploy	pip	>= 0.9.2, < 0.16.0	`0.16.0`
8.1K 1 dependents Pushed 8d ago 60% patched ~17d to patch Full package profile →

Do you use LMDeploy? You're affected.

How severe is it?

CVSS 3.1

9.8 / 10

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

N/A

What is the attack surface?

AV Network

AC Low

PR None

UI None

S Unchanged

C High

I High

A High

What should I do?

Patch available

Update LMDeploy to version 0.16.0

Which compliance frameworks are affected?

Compliance analysis pending. Sign in for full compliance mapping when available.

Frequently Asked Questions

What is CVE-2025-66455?

LMDeploy is a toolkit for compressing, deploying, and serving large language models. Starting in version 0.9.2 and prior to version 0.16.0, LMDeploy's PyTorch DistServe/PD-disaggregation control plane used `recv_pyobj()` to deserialize messages received through a ZeroMQ PULL socket. PyZMQ implements `recv_pyobj()` using Python pickle deserialization, which can execute arbitrary code while reconstructing an object. The peer address used by the receiver was supplied through the `POST /distserve/p2p_connect` HTTP endpoint. An attacker who could reach an affected DistServe API server could cause the server to connect to an attacker-controlled ZeroMQ endpoint and deserialize a crafted pickle payload. API-key authentication is not enabled unless the operator explicitly configures it. As a result, affected DistServe deployments without API keys allowed unauthenticated remote code execution with the privileges of the LMDeploy serving process. This issue affects the PyTorch backend when PD-disaggregation/DistServe is enabled. Ordinary deployments that do not use the affected disaggregated-serving path do not expose this data flow. The fix was released in LMDeploy 0.16.0. Users who cannot upgrade immediately should prevent untrusted clients from reaching `/distserve/*` endpoints, restrict the DistServe HTTP and ZeroMQ control planes to trusted cluster networks, configure API-key authentication, and block arbitrary outbound ZeroMQ connections from serving nodes. These measures reduce exposure but do not make pickle deserialization safe.

Is CVE-2025-66455 actively exploited?

No confirmed active exploitation of CVE-2025-66455 has been reported, but organizations should still patch proactively.

How to fix CVE-2025-66455?

Update to patched version: LMDeploy 0.16.0.

What is the CVSS score for CVE-2025-66455?

CVE-2025-66455 has a CVSS v3.1 base score of 9.8 (CRITICAL).

What are the technical details?

Original Advisory

LMDeploy is a toolkit for compressing, deploying, and serving large language models. Starting in version 0.9.2 and prior to version 0.16.0, LMDeploy's PyTorch DistServe/PD-disaggregation control plane used `recv_pyobj()` to deserialize messages received through a ZeroMQ PULL socket. PyZMQ implements `recv_pyobj()` using Python pickle deserialization, which can execute arbitrary code while reconstructing an object. The peer address used by the receiver was supplied through the `POST /distserve/p2p_connect` HTTP endpoint. An attacker who could reach an affected DistServe API server could cause the server to connect to an attacker-controlled ZeroMQ endpoint and deserialize a crafted pickle payload. API-key authentication is not enabled unless the operator explicitly configures it. As a result, affected DistServe deployments without API keys allowed unauthenticated remote code execution with the privileges of the LMDeploy serving process. This issue affects the PyTorch backend when PD-disaggregation/DistServe is enabled. Ordinary deployments that do not use the affected disaggregated-serving path do not expose this data flow. The fix was released in LMDeploy 0.16.0. Users who cannot upgrade immediately should prevent untrusted clients from reaching `/distserve/*` endpoints, restrict the DistServe HTTP and ZeroMQ control planes to trusted cluster networks, configure API-key authentication, and block arbitrary outbound ZeroMQ connections from serving nodes. These measures reduce exposure but do not make pickle deserialization safe.

Weaknesses (CWE)

CWE-502 Deserialization of Untrusted Data Primary CWE-502 Deserialization of Untrusted Data Primary CWE-502 Deserialization of Untrusted Data

CWE-502 — Deserialization of Untrusted Data: The product deserializes untrusted data without sufficiently ensuring that the resulting data will be valid.

[Architecture and Design, Implementation] If available, use the signing/sealing features of the programming language to assure that deserialized data has not been tainted. For example, a hash-based message authentication code (HMAC) could be used to ensure that data has not been modified.
[Implementation] When deserializing data, populate a new object rather than just deserializing. The result is that the data flows through safe input validation and that the functions are safe.

Source: MITRE CWE corpus.