CVE-2026-33625: LMDeploy: eval() injection via malicious model config

Q: Is CVE-2026-33625 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-33625, increasing the risk of exploitation.

Q: How to fix CVE-2026-33625?

1) Upgrade lmdeploy to 0.12.3 or later. 2) Inventory hosts running lmdeploy 0.12.1-0.12.2 via pip freeze or SBOM tooling. 3) Until patched, load models only from trusted organizations, pin to specific commit hashes, and review config.json (especially quantization_config.quant_dtype) before loading. 4) Run inference workloads in sandboxed containers with least-privilege, no long-lived cloud credentials, and restricted egress. 5) Detection: alert on unexpected child processes, outbound connections or file writes from lmdeploy serving processes, and audit recent model downloads for non-standard quant_dtype values containing parentheses, dunder names or import statements.

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

This vulnerability affects the following AI/ML architecture patterns: model serving, LLM inference servers, model deployment pipelines, quantized model workflows, model registry consumers.

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

CVE-2026-33625 has a CVSS v3.1 base score of 8.8 (HIGH). The EPSS exploitation probability is 0.44%.

GHSA-3hmm-rh5q-gwwrHIGHPoC AVAILABLECISA: ATTEND

Published September 18, 2026

CISO Take

LMDeploy, a popular LLM serving toolkit, passes the `quantization_config.quant_dtype` value from a HuggingFace model config straight into Python's `eval()`, so anyone who can publish a model can run arbitrary code on the machine that loads it. The attack needs only a user to load the model (CVSS 8.8, network vector, low complexity, no privileges), and organizations routinely pull community models into inference clusters that hold GPUs, API keys and proprietary data. Near-term mass exploitation looks limited: EPSS is 0.44% (64th percentile), CISA SSVC says ATTEND, there is no public exploit or Nuclei template, and it is not in CISA KEV. Even so, the package has 9 other CVEs and the model-supply-chain vector is easy to weaponize. Upgrade to lmdeploy 0.12.3 or later, and until then load models only from vetted, pinned sources.

Sources:NVDEPSSGitHub AdvisoryATLAS

What is the risk?

High severity, moderate near-term likelihood. Exploitation is trivial for anyone able to publish or tamper with a model repository, since a single crafted JSON field triggers eval(). The user-interaction requirement is easily met because loading a model is routine in model-serving workflows. Exploitation probability signals are modest (EPSS 0.00442, no public PoC, not in KEV), but impact is full confidentiality, integrity and availability compromise of the inference host. Only versions >= 0.12.1 and < 0.12.3 are affected, which narrows exposure. The CWE labeling (CWE-400) does not match the actual code-injection flaw, so scanners keyed on CWE may misclassify it.

How does the attack unfold?

Malicious model publication

Attacker publishes or tampers with a HuggingFace model whose quantization_config.quant_dtype contains a Python payload.

AML.T0058

Victim loads model

A user or pipeline loads the model with lmdeploy 0.12.1-0.12.2, delivering the poisoned config.

AML.T0011.000

Code execution

The unvalidated quant_dtype is passed to eval(), running arbitrary Python in the serving process.

AML.T0050

Impact

Attacker gains host control, steals credentials and model assets, and pivots into ML infrastructure.

AML.T0112.001

Malicious model publication

Attacker publishes or tampers with a HuggingFace model whose quantization_config.quant_dtype contains a Python payload.

AML.T0058

Victim loads model

A user or pipeline loads the model with lmdeploy 0.12.1-0.12.2, delivering the poisoned config.

AML.T0011.000

Code execution

The unvalidated quant_dtype is passed to eval(), running arbitrary Python in the serving process.

AML.T0050

Impact

Attacker gains host control, steals credentials and model assets, and pivots into ML infrastructure.

AML.T0112.001

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
LMDeploy	pip	>= 0.12.1, < 0.12.3	`0.12.3`
8.1K1 dependentsPushed 4d ago46% patched~18d to patchFull package profile →

Do you use LMDeploy? You're affected.

How severe is it?

CVSS 3.1

8.8 / 10

EPSS

0.4%

chance of exploitation in 30 days

Higher than 38% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Trivial

Exploitation Confidence

medium

○CISA SSVC: Public PoC

○Public PoC indexed (trickest/cve)

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?

AVNetwork

ACLow

PRNone

UIRequired

SUnchanged

CHigh

IHigh

AHigh

What should I do?

1 step

1) Upgrade lmdeploy to 0.12.3 or later. 2) Inventory hosts running lmdeploy 0.12.1-0.12.2 via pip freeze or SBOM tooling. 3) Until patched, load models only from trusted organizations, pin to specific commit hashes, and review config.json (especially quantization_config.quant_dtype) before loading. 4) Run inference workloads in sandboxed containers with least-privilege, no long-lived cloud credentials, and restricted egress. 5) Detection: alert on unexpected child processes, outbound connections or file writes from lmdeploy serving processes, and audit recent model downloads for non-standard quant_dtype values containing parentheses, dunder names or import statements.

What does CISA's SSVC say?

DecisionAttend

Exploitationpoc

AutomatableNo

Technical Impacttotal

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

How is it classified?

Code ExecutionSupply ChainInferenceFrameworkModelAML.T0010.003- Model AML.T0011.000- Unsafe AI Artifacts AML.T0050- Command and Scripting Interpreter AML.T0058- Publish Poisoned Models AML.T0112.001- AI Artifacts

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art. 15-Accuracy, robustness and cybersecurity

ISO 42001

A.10.3-Suppliers

NIST AI RMF

MAP 4.1-Risks of third-party software, data and models are mapped

OWASP LLM Top 10

LLM03-Supply Chain

Frequently Asked Questions

What is CVE-2026-33625?

Is CVE-2026-33625 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-33625, increasing the risk of exploitation.

How to fix CVE-2026-33625?

1) Upgrade lmdeploy to 0.12.3 or later. 2) Inventory hosts running lmdeploy 0.12.1-0.12.2 via pip freeze or SBOM tooling. 3) Until patched, load models only from trusted organizations, pin to specific commit hashes, and review config.json (especially quantization_config.quant_dtype) before loading. 4) Run inference workloads in sandboxed containers with least-privilege, no long-lived cloud credentials, and restricted egress. 5) Detection: alert on unexpected child processes, outbound connections or file writes from lmdeploy serving processes, and audit recent model downloads for non-standard quant_dtype values containing parentheses, dunder names or import statements.

What systems are affected by CVE-2026-33625?

This vulnerability affects the following AI/ML architecture patterns: model serving, LLM inference servers, model deployment pipelines, quantized model workflows, model registry consumers.

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

CVE-2026-33625 has a CVSS v3.1 base score of 8.8 (HIGH). The EPSS exploitation probability is 0.44%.

What is the AI security impact?

Affected AI Architectures

model servingLLM inference serversmodel deployment pipelinesquantized model workflowsmodel registry consumers

MITRE ATLAS Techniques

AML.T0010.003Model

AML.T0011.000Unsafe AI Artifacts

AML.T0050Command and Scripting Interpreter

AML.T0058Publish Poisoned Models

AML.T0112.001AI Artifacts

Compliance Controls Affected

EU AI Act: Art. 15

ISO 42001: A.10.3

NIST AI RMF: MAP 4.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. Versions 012.1 through 0.12.2 contain a code injection vulnerability in `lmdeploy/pytorch/config.py` line 620 that allows an attacker to execute arbitrary Python code by publishing a malicious HuggingFace model with a crafted `quantization_config.quant_dtype` value. When a user loads the model with lmdeploy, the `quant_dtype` is passed to `eval(f'torch.{quant_dtype}')` without any validation. Version 0.12.3 contains a patch.

Exploitation Scenario

An attacker publishes a plausible-looking fine-tuned or quantized model on HuggingFace, or compromises an existing repository, with a config.json whose quant_dtype is a Python expression such as an __import__ call that spawns a reverse shell. An ML engineer or an automated deployment pipeline pulls the model and starts it with lmdeploy. The eval() executes the payload on load, giving the attacker a shell on the GPU inference host, from which they steal cloud and API credentials, exfiltrate proprietary models and data, and move laterally into the ML platform.

Weaknesses (CWE)

CWE-400Uncontrolled Resource ConsumptionPrimary CWE-400Uncontrolled Resource ConsumptionPrimary CWE-400Uncontrolled Resource Consumption

CWE-400 — Uncontrolled Resource Consumption: The product does not properly control the allocation and maintenance of a limited resource.

[Architecture and Design] Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.
[Architecture and Design] Mitigation of resource exhaustion attacks requires that the target system either: The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question. The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker. recognizes the attack and denies that user further access for a given amount of time, or uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.

Source: MITRE CWE corpus.