LMDeploy CVE-2026-46517 — hardcoded trust_remote_code bypasses HF default-secure

AI relevance: LMDeploy is a production model serving framework used in AI inference pipelines; hardcoding trust_remote_code=True means any model load can silently execute arbitrary Python from HuggingFace repos, collapsing the trust boundary that vLLM and HF Transformers enforce by default.

  • Root cause: Four call sites across LMDeploy — get_model_arch(), calibrate CLI, calibration helpers, and the PyTorch env checker — all hardcode trust_remote_code=True with no CLI flag, env var, or parameter to override.
  • Silent override: HuggingFace Transformers ≥ 4.30 made trust_remote_code=False the default to prevent exactly this class of supply-chain RCE. LMDeploy unilaterally reverses that safeguard.
  • Not a network RCE: The reporter clarified this is not an unauthenticated remote exploit — the user must supply the repo name. But the CVSS was revised to 5.5 Medium with the qualifier that any typo or malicious repo name executes attacker Python immediately.
  • Ecosystem contrast: vLLM, TGI, and HF Transformers all expose --trust-remote-code as an opt-in flag. LMDeploy is the outlier that forces trust.
  • Attack path: A malicious HF repo with a configuration_*.py shim runs Python as the LMDeploy user at the very first call to get_model_arch() — before any model weights are even loaded.
  • Fix: The proposed patch is a single-line change: thread trust_remote_code through all three call sites, defaulting to False.
  • Coordinated disclosure: 90-day window from initial vendor email; advisory published under GHSA-9xq9-36w5-q796.

Why it matters

Teams running LMDeploy for model serving assume they're operating within the same trust model as the rest of the HF ecosystem. They aren't. Any researcher or engineer loading a third-party model through LMDeploy is executing remote code without opt-in — a default-insecure stance that the entire HF community has spent years correcting.

What to do

Sources