What is the CVSS score of CVE-2025-67729?

CVE-2025-67729 has a CVSS 3.1 base score of 8.8 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.6%.

Which versions of LMDeploy are affected by CVE-2025-67729?

A high-severity remote code execution flaw affects InternLM LMDeploy 0.11 and earlier, the model quantization and serving toolkit used by teams deploying large language models.. A patch is available.

How to fix or mitigate CVE-2025-67729?

Within 24 hours, identify every LMDeploy installation at version 0.11 or earlier across workstations, build pipelines, and serving infrastructure, and treat all untrusted or third-party .bin, .pt, and .pth checkpoints as hostile pending remediation. Within 7 days, upgrade all affected installations to the vendor-released patch version 0.11.1, and where an immediate upgrade is not possible, restrict checkpoint loading to .safetensors files and enforce policy that only first-party, integrity-verified weights are supplied to the quantization and deployment APIs, including the TurboMind PytorchLoader and the VL model loader. Within 30 days, add automated dependency scanning to flag LMDeploy versions below 0.11.1 in CI/CD, require hash or signature verification of all model artifacts before they reach a loader, and audit the last 90 days of logs on any host that processed externally sourced checkpoints for signs of unexpected code execution or outbound connections. Note that exploitation is unauthenticated in the sense of requiring no credentials (CVSS PR:N) but is gated by user interaction (UI:R), so awareness training for ML engineers on untrusted checkpoint sources should accompany the technical fixes.

LMDeploy CVE-2025-67729

HIGH

Deserialization of Untrusted Data (CWE-502)

2025-12-26 security-advisories@github.com

RCE Deserialization Lmdeploy Checkpoint Internlm

8.8

CVSS 3.1 · Vendor: github

Severity by source

Vendor (github) PRIMARY

8.8 HIGH

AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

vuln.today AI

8.8 HIGH

Malicious checkpoints are typically network-sourced (AV:N) and need no attacker privileges (PR:N), but the victim must load the file (UI:R); pickle deserialization yields full RCE, so C/I/A all High.

3.1 AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

4.0 AV:N/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (github).

CVSS VectorVendor: github

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

Required

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Generated

Oct 05, 2026 - 19:40 vuln.today

CVE Published

Dec 26, 2025 - 22:15 cve.org

HIGH 8.8

DescriptionCVE.org

LMDeploy is a toolkit for compressing, deploying, and serving LLMs. Prior to version 0.11.1, an insecure deserialization vulnerability exists in lmdeploy where torch.load() is called without the weights_only=True parameter when loading model checkpoint files. This allows an attacker to execute arbitrary code on the victim's machine when they load a malicious .bin or .pt model file. This issue has been patched in version 0.11.1.

AnalysisAI

Arbitrary code execution in InternLM LMDeploy 0.11 and earlier: the toolkit calls torch.load() without weights_only=True when loading model checkpoint files, so a malicious .bin, .pt or .pth checkpoint executes attacker-supplied code during deserialization. Exploitation is unauthenticated in the sense of no credentials (CVSS PR:N) but is gated by user interaction (UI:R) - the victim must deliberately point LMDeploy at an attacker-controlled checkpoint through the quantization/deployment APIs, the TurboMind PytorchLoader, or the VL model loader; requests to LMDeploy's serving path with trusted first-party weights are unaffected, and .safetensors checkpoints use a safe loader. Publicly available exploit code exists in the GitHub advisory, and the issue is resolved in 0.11.1; no confirmed active exploitation (CISA KEV) was identified at time of analysis.

Technical ContextAI

The root cause is CWE-502 (Deserialization of Untrusted Data). PyTorch's torch.load() dispatches to Python's pickle module when reading legacy checkpoint formats, and pickle reconstructs arbitrary objects by invoking callables returned from an object's __reduce__ method - a standard code-execution primitive (os.system, subprocess, etc.). Only the weights_only=True argument restricts the unpickler to tensors and primitive containers, blocking the pickle reduce path. The advisory documents that LMDeploy already used the secure pattern in lmdeploy/pytorch/weight_loader/model_weight_loader.py (line 103) but omitted it in at least six other locations: lmdeploy/vl/model/utils.py (line 22, load_weight_ckpt, which only falls back to torch.load for non-.safetensors files), lmdeploy/turbomind/deploy/loader.py (line 122, PytorchLoader.items), lmdeploy/lite/apis/kv_qparams.py (lines 129-130, key_stats.pth and value_stats.pth), lmdeploy/lite/apis/smooth_quant.py (line 61), lmdeploy/lite/apis/auto_awq.py (line 101, inputs_stats.pth) and lmdeploy/lite/apis/get_small_sharded_hf.py (line 41). The affected technology is the LLM compression/quantization and deployment toolchain that consumes third-party model weights - a supply-chain-relevant surface because users routinely pull checkpoints from model hubs. The upstream fix (commit eb04b428) adds weights_only=True to the auto_awq and get_small_sharded_hf call sites and removes the vulnerable kv_qparams.py module entirely. The RCE/Deserialization/Lmdeploy/Checkpoint tags and the CPE cpe:2.3:a:internlm:lmdeploy:*:*:*:*:*:*:*:* confirm the entire LMDeploy package line is the affected product family. The assessed CVSS vector AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H matches the advisory and the auth/interaction model: no privileges required, but the vector's UI:R reflects that the victim must actively load the hostile checkpoint, so this is not a remote unattended or drive-by trigger.

RemediationAI

Upgrade to LMDeploy 0.11.1 or later - vendor-released patch that applies weights_only=True at the vulnerable torch.load() call sites; the upstream fix is commit https://github.com/InternLM/lmdeploy/commit/eb04b4281c5784a5cff5ea639c8f96b33b3ae5ee and the advisory is https://github.com/InternLM/lmdeploy/security/advisories/GHSA-9pf3-7rrr-x5jh. Where an immediate upgrade is not possible, the highest-value compensating control is to accept only .safetensors checkpoints and reject .bin/.pt/.pth inputs, since LMDeploy's safetensors branch already bypasses pickle; the trade-off is that many community checkpoints are still distributed in legacy PyTorch format, so conversion to safetensors must be done once in a quarantined environment before use. Second, treat every downloaded checkpoint as untrusted code: convert it inside a disposable container or VM with no host credentials, network egress or mounted secrets, accepting the operational cost of a sandboxed conversion step. Third, if you maintain a fork or vendored copy, add weights_only=True explicitly to the affected call sites (vl/model/utils.py load_weight_ckpt, turbomind/deploy/loader.py PytorchLoader.items, lite/apis/smooth_quant.py and lite/apis/auto_awq.py) or backport the upstream commit; note that weights_only=True can fail on checkpoints containing non-tensor Python objects, which may require regenerating the checkpoint with the newer serializer. Do not rely on restricting the lmdeploy serving endpoint, since the trigger is local file loading (UI:R) rather than a network request - access controls on the HTTP API do not reduce this risk. There is no vendor-released workaround beyond the 0.11.1 upgrade.