lmdeploy: Hardcoded trust_remote_code=True is an implicit unsafe remote-code load path with no user opt-out

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

CVSS 3.1

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

Severity from

GitHub (reviewed advisory)

Weakness

CWE-1188, CWE-915, CWE-94

Also known as

CVE-2026-46517, PYSEC-2026-2608

• github.com/InternLM/lmdeploy/security/advisories/GHSA-9xq9-36w5-q796
• nvd.nist.gov/vuln/detail/CVE-2026-46517
• github.com/github/advisory-database/pull/4511
• github.com/InternLM/lmdeploy/commit/81be52961aa324fd5cd3cacebffba1ba051bc107
• github.com/InternLM/lmdeploy
• github.com/InternLM/lmdeploy/blob/v0.13.0/lmdeploy/version.py
• github.com/InternLM/lmdeploy/releases/tag/v0.13.0
• github.com/pypa/advisory-database/tree/main/vulns/lmdeploy/PYSEC-2026-2608.yaml