CVE-2026-79721: MLflow malicious model

CISO Take

MLflow, one of the most widely deployed MLOps platforms for experiment tracking and model registries, will execute arbitrary attacker-controlled code whenever a maliciously crafted model artifact is loaded — a flaw present since version 0.0.1, meaning virtually every deployment in production today is exposed. There is no CVSS score, EPSS data, or CISA KEV listing yet, and no public exploit or scanner template has surfaced, so this has not been mass-weaponized, but the root cause is the well-understood pattern of unsafe deserialization in model files (CWE-829), which threat actors have repeatedly abused against ML pipelines. The real risk is blast radius: any team that pulls models from a shared registry, third-party source, or automated CI/CD pipeline is one `mlflow.pyfunc.load_model` call away from full code execution on the loading host, including credential theft and lateral movement into training/serving infrastructure. Treat model loading as untrusted code execution — restrict model sources to signed/verified artifacts, scan pickle-based files with tools like `fickling` or `picklescan` before load, and run loading in isolated, network-restricted service accounts until MLflow ships a fix or hardened loading mode.

Sources: NVD ATLAS hiddenlayer.com

What is the risk?

No CVSS or EPSS score is published and the CVE is not in CISA KEV, so near-term mass exploitation cannot be confirmed at this time. However, the vulnerability class (arbitrary code execution via untrusted deserialization of a model artifact) is well-documented and easy to reproduce for anyone familiar with Python pickle exploitation — public tooling for crafting malicious pickles is widely available even without a dedicated PoC for this specific CVE. Because the flaw affects MLflow from its very first release (0.0.1+) with no version ceiling given, exposure is effectively universal across MLflow deployments that load models from any source outside full organizational control (shared registries, external contributors, downloaded pretrained models). This elevates the practical risk well above what the missing CVSS score suggests, particularly for organizations with open or loosely governed model registries.

How does the attack unfold?

Malicious Model Publication

Attacker crafts a model artifact embedding a malicious deserialization payload and publishes or plants it in a shared/public MLflow model registry or artifact store.

AML.T0058

Victim Loads Model

A user, CI/CD pipeline, or serving system pulls and loads the artifact via MLflow's model-loading API as part of normal workflow.

AML.T0011.000

Code Execution

Deserialization of the artifact triggers execution of the embedded malicious code on the loading host.

AML.T0018.002

Impact

Attacker gains a foothold on the training/CI/serving host, enabling credential theft, lateral movement, or further tampering with the ML pipeline.

AML.T0112.001

Malicious Model Publication

Attacker crafts a model artifact embedding a malicious deserialization payload and publishes or plants it in a shared/public MLflow model registry or artifact store.

AML.T0058

Victim Loads Model

A user, CI/CD pipeline, or serving system pulls and loads the artifact via MLflow's model-loading API as part of normal workflow.

AML.T0011.000

Code Execution

Deserialization of the artifact triggers execution of the embedded malicious code on the loading host.

AML.T0018.002

Impact

Attacker gains a foothold on the training/CI/serving host, enabling credential theft, lateral movement, or further tampering with the ML pipeline.

AML.T0112.001

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
MLflow	pip	—	No patch
27.9K OpenSSF 5.4 694 dependents Pushed 6d ago 36% patched ~73d to patch Full package profile →

Do you use MLflow? You're affected.

How severe is it?

CVSS 3.1

N/A

EPSS

0.3%

chance of exploitation in 30 days

Higher than 22% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Moderate

Exploitation Confidence

medium

○ 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 should I do?

1 step

1) Treat every model artifact as untrusted code: never load models from unverified sources, external contributors, or public registries without review. 2) Scan model files with pickle-safety tools (fickling, picklescan) before loading, and prefer non-pickle serialization formats (e.g., ONNX, SafeTensors) where the MLflow flavor supports them. 3) Run model-loading operations (training-to-production promotion, CI/CD, serving startup) in isolated, least-privilege, network-restricted containers/service accounts with no access to sensitive credentials or internal networks. 4) Enforce artifact provenance and signing on the MLflow Model Registry — restrict who can register/promote model versions. 5) Monitor for the HiddenLayer advisory and MLflow's release notes for an official patched version and upgrade as soon as one is published. 6) Add detection for anomalous process spawning or outbound connections originating from MLflow tracking-server or model-loading hosts.

What does CISA's SSVC say?

Decision Track

Exploitation none

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 Framework Model AML.T0010.003 - Model AML.T0011.000 - Unsafe AI Artifacts AML.T0018.002 - Embed Malware AML.T0058 - Publish Poisoned Models

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.10.2 - Third-party and supplier relationships for AI system components

NIST AI RMF

GOVERN-6.1 - Third-party risks and responsibilities

OWASP LLM Top 10

LLM05 - Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2026-79721?

MLflow, one of the most widely deployed MLOps platforms for experiment tracking and model registries, will execute arbitrary attacker-controlled code whenever a maliciously crafted model artifact is loaded — a flaw present since version 0.0.1, meaning virtually every deployment in production today is exposed. There is no CVSS score, EPSS data, or CISA KEV listing yet, and no public exploit or scanner template has surfaced, so this has not been mass-weaponized, but the root cause is the well-understood pattern of unsafe deserialization in model files (CWE-829), which threat actors have repeatedly abused against ML pipelines. The real risk is blast radius: any team that pulls models from a shared registry, third-party source, or automated CI/CD pipeline is one `mlflow.pyfunc.load_model` call away from full code execution on the loading host, including credential theft and lateral movement into training/serving infrastructure. Treat model loading as untrusted code execution — restrict model sources to signed/verified artifacts, scan pickle-based files with tools like `fickling` or `picklescan` before load, and run loading in isolated, network-restricted service accounts until MLflow ships a fix or hardened loading mode.

Is CVE-2026-79721 actively exploited?

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

How to fix CVE-2026-79721?

1) Treat every model artifact as untrusted code: never load models from unverified sources, external contributors, or public registries without review. 2) Scan model files with pickle-safety tools (`fickling`, `picklescan`) before loading, and prefer non-pickle serialization formats (e.g., ONNX, SafeTensors) where the MLflow flavor supports them. 3) Run model-loading operations (training-to-production promotion, CI/CD, serving startup) in isolated, least-privilege, network-restricted containers/service accounts with no access to sensitive credentials or internal networks. 4) Enforce artifact provenance and signing on the MLflow Model Registry — restrict who can register/promote model versions. 5) Monitor for the HiddenLayer advisory and MLflow's release notes for an official patched version and upgrade as soon as one is published. 6) Add detection for anomalous process spawning or outbound connections originating from MLflow tracking-server or model-loading hosts.

What systems are affected by CVE-2026-79721?

This vulnerability affects the following AI/ML architecture patterns: model serving, MLOps pipelines, model registries, training pipelines.

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

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

model servingMLOps pipelinesmodel registriestraining pipelines

MITRE ATLAS Techniques

AML.T0010.003 Model

AML.T0011.000 Unsafe AI Artifacts

AML.T0018.002 Embed Malware

AML.T0058 Publish Poisoned Models

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.10.2

NIST AI RMF: GOVERN-6.1

OWASP LLM Top 10: LLM05

What are the technical details?

Original Advisory

Code execution can occur in versions of the MLflow platform running version 0.0.1 or newer, enabling a maliciously crafted model artifact to execute arbitrary code on an end user's system when loaded by the project.

Exploitation Scenario

An adversary crafts a model artifact (e.g., a pickled sklearn/pytorch model) embedding a malicious `__reduce__` payload and publishes it under a plausible name to a shared or public MLflow model registry, a compromised internal registry, or as a 'helpful' contribution to a team's model repo. A data scientist, MLOps engineer, or automated CI/CD pipeline then loads the model via MLflow's load API as part of normal evaluation, promotion, or serving deployment. The instant the artifact is deserialized, the embedded payload executes with the privileges of the loading process — potentially a CI runner or production serving host — giving the attacker a foothold to exfiltrate credentials, pivot into the training/serving environment, or tamper with other models in the registry.

Weaknesses (CWE)

CWE-829 Inclusion of Functionality from Untrusted Control Sphere CWE-829 Inclusion of Functionality from Untrusted Control Sphere

CWE-829 — Inclusion of Functionality from Untrusted Control Sphere: The product imports, requires, or includes executable functionality (such as a library) from a source that is outside of the intended control sphere.

[Architecture and Design] Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482].
[Architecture and Design] When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs. For example, ID 1 could map to "inbox.txt" and ID 2 could map to "profile.txt". Features such as the ESAPI AccessReferenceMap [REF-45] provide this capability.

Source: MITRE CWE corpus.