CVE-2026-2651: MLflow auth bypass on artifact

Q: Is CVE-2026-2651 actively exploited?

No confirmed active exploitation of CVE-2026-2651 has been reported, but organizations should still patch proactively.

Q: How to fix CVE-2026-2651?

Upgrade to the patched MLflow release (3.10.0 per the vendor advisory; verify against your build since package metadata references the 3.11.0rc1 line — deploy the latest stable ≥3.10/3.11 release regardless). If immediate upgrade isn't possible: disable `--serve-artifacts` or gate it behind an authenticating reverse proxy that enforces per-user/per-run path checks; segment tracking servers so unrelated teams don't share one instance; enforce artifact integrity checks (hashing/signing) before any model is loaded downstream; run uploaded model files through a deserialization scanner (e.g. picklescan, fickling) before `mlflow.pyfunc.load_model()` is called; and audit `/mlflow-artifacts/mpu/*` access logs since disclosure for writes targeting artifact paths outside the requesting user's own runs.

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

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

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

CVE-2026-2651 has a CVSS v3.1 base score of 9.0 (CRITICAL). The EPSS exploitation probability is 0.34%.

CISO Take

MLflow's multipart-upload endpoints for artifact storage skip resource-level authorization checks, so any low-privileged user on a shared tracking server can overwrite artifacts — including registered models — that belong to someone else. With 660 downstream dependents and MLflow serving as the de facto model registry in countless ML pipelines, this turns a simple missing-authz bug into a direct supply-chain poisoning vector: swap a legitimate model file for a malicious one, and whatever loads it next inherits arbitrary code execution via deserialization. EPSS sits at 0.35% (73rd percentile) and the flaw isn't in CISA KEV, and CISA's SSVC verdict of ATTEND reflects that no active exploitation has been observed yet, but the CVSS 9.0 score (network, low complexity, changed scope, full C/I/A impact) shows how little an attacker needs once they hold any account on an exposed instance. No public exploit or Nuclei template exists today, so patch to the fixed release now, restrict `--serve-artifacts` to trusted networks, and audit artifact ownership/ACLs on any multi-tenant MLflow deployment before this becomes weaponized.

Sources: NVD GitHub Advisory EPSS OpenSSF ATLAS huntr.com access.redhat.com

What is the risk?

Critical on paper (CVSS 9.0) but currently a targeted rather than mass-exploitation risk: EPSS is low (0.35%, 73rd percentile), there's no CISA KEV listing, no public PoC, and no Nuclei template, and CISA's own SSVC decision is ATTEND rather than ACT/ACT-NOW. That said, the prerequisites are modest — network access, low privileges (any authenticated account), and one instance of required user interaction — against a package with a 81/100 internal risk score, a 5.4/10 OpenSSF Scorecard, and a history of 73 other CVEs, indicating MLflow is both widely deployed and a recurring target. Exposure is entirely conditional on `--serve-artifacts` mode being enabled and on the tracking server being shared across users/teams (multi-tenant MLOps platforms, internal ML shared services) — single-tenant or air-gapped deployments are effectively unaffected.

How does the attack unfold?

Initial Access

Attacker obtains or registers a low-privilege account on a shared MLflow tracking server running with --serve-artifacts enabled.

AML.T0012

Exploitation

Attacker calls /mlflow-artifacts/mpu/* endpoints, which lack resource-level authorization, to write to another user's artifact path.

AML.T0049

Model Poisoning

Attacker overwrites the legitimate model artifact with a malicious pickle file containing an embedded payload.

AML.T0018.002

Impact

A downstream pipeline or user loads the poisoned model, triggering deserialization and granting the attacker code execution.

AML.T0011.000

Initial Access

Attacker obtains or registers a low-privilege account on a shared MLflow tracking server running with --serve-artifacts enabled.

AML.T0012

Exploitation

Attacker calls /mlflow-artifacts/mpu/* endpoints, which lack resource-level authorization, to write to another user's artifact path.

AML.T0049

Model Poisoning

Attacker overwrites the legitimate model artifact with a malicious pickle file containing an embedded payload.

AML.T0018.002

Impact

A downstream pipeline or user loads the poisoned model, triggering deserialization and granting the attacker code execution.

AML.T0011.000

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
MLflow	pip	< 3.11.0rc0	`3.11.0rc1`
27.4K OpenSSF 5.4 680 dependents Pushed 2d ago 33% patched ~77d to patch Full package profile →
MLflow	pip	—	No patch
27.4K OpenSSF 5.4 680 dependents Pushed 2d ago 33% patched ~77d to patch Full package profile →

How severe is it?

CVSS 3.1

9.0 / 10

EPSS

0.3%

chance of exploitation in 30 days

Higher than 27% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Moderate

Exploitation Confidence

medium

○ CISA SSVC: Public PoC

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?

AV Network

AC Low

PR Low

UI Required

S Changed

C High

I High

A High

What should I do?

1 step

Upgrade to the patched MLflow release (3.10.0 per the vendor advisory; verify against your build since package metadata references the 3.11.0rc1 line — deploy the latest stable ≥3.10/3.11 release regardless). If immediate upgrade isn't possible: disable --serve-artifacts or gate it behind an authenticating reverse proxy that enforces per-user/per-run path checks; segment tracking servers so unrelated teams don't share one instance; enforce artifact integrity checks (hashing/signing) before any model is loaded downstream; run uploaded model files through a deserialization scanner (e.g. picklescan, fickling) before mlflow.pyfunc.load_model() is called; and audit /mlflow-artifacts/mpu/* access logs since disclosure for writes targeting artifact paths outside the requesting user's own runs.

What does CISA's SSVC say?

Decision Attend

Exploitation poc

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 Auth Bypass Code Execution Model Inference Framework AML.T0010.001 - AI Software AML.T0010.003 - Model 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.6.2.4 - AI system life cycle — secure development and deployment

NIST AI RMF

GOVERN-6.1 - Policies and procedures for third-party/supply-chain AI risks

OWASP LLM Top 10

LLM03 - Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2026-2651?

MLflow's multipart-upload endpoints for artifact storage skip resource-level authorization checks, so any low-privileged user on a shared tracking server can overwrite artifacts — including registered models — that belong to someone else. With 660 downstream dependents and MLflow serving as the de facto model registry in countless ML pipelines, this turns a simple missing-authz bug into a direct supply-chain poisoning vector: swap a legitimate model file for a malicious one, and whatever loads it next inherits arbitrary code execution via deserialization. EPSS sits at 0.35% (73rd percentile) and the flaw isn't in CISA KEV, and CISA's SSVC verdict of ATTEND reflects that no active exploitation has been observed yet, but the CVSS 9.0 score (network, low complexity, changed scope, full C/I/A impact) shows how little an attacker needs once they hold any account on an exposed instance. No public exploit or Nuclei template exists today, so patch to the fixed release now, restrict `--serve-artifacts` to trusted networks, and audit artifact ownership/ACLs on any multi-tenant MLflow deployment before this becomes weaponized.

Is CVE-2026-2651 actively exploited?

No confirmed active exploitation of CVE-2026-2651 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-2651?

Upgrade to the patched MLflow release (3.10.0 per the vendor advisory; verify against your build since package metadata references the 3.11.0rc1 line — deploy the latest stable ≥3.10/3.11 release regardless). If immediate upgrade isn't possible: disable `--serve-artifacts` or gate it behind an authenticating reverse proxy that enforces per-user/per-run path checks; segment tracking servers so unrelated teams don't share one instance; enforce artifact integrity checks (hashing/signing) before any model is loaded downstream; run uploaded model files through a deserialization scanner (e.g. picklescan, fickling) before `mlflow.pyfunc.load_model()` is called; and audit `/mlflow-artifacts/mpu/*` access logs since disclosure for writes targeting artifact paths outside the requesting user's own runs.

What systems are affected by CVE-2026-2651?

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

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

CVE-2026-2651 has a CVSS v3.1 base score of 9.0 (CRITICAL). The EPSS exploitation probability is 0.34%.

What is the AI security impact?

Affected AI Architectures

model servingtraining pipelinesMLOps/model registryCI/CD ML pipelines

MITRE ATLAS Techniques

AML.T0010.001 AI Software

AML.T0010.003 Model

AML.T0018.002 Embed Malware

AML.T0058 Publish Poisoned Models

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2.4

NIST AI RMF: GOVERN-6.1

OWASP LLM Top 10: LLM03

What are the technical details?

Original Advisory

A vulnerability in MLflow versions <=3.10.1.dev0 allows unauthorized access to multipart upload (MPU) endpoints when the `--serve-artifacts` mode is enabled. The authorization logic does not enforce resource-level permission checks for `/mlflow-artifacts/mpu/*` endpoints, enabling attackers to overwrite artifacts belonging to other users. This can lead to unauthorized cross-user writes, model supply chain poisoning, and arbitrary code execution when compromised models are loaded. The issue is resolved in version 3.10.0.

Exploitation Scenario

An attacker registers or obtains a low-privilege account on a shared MLflow tracking server running with `--serve-artifacts` enabled — common on internal multi-tenant ML platforms. They enumerate other users' run/experiment artifact paths (often predictable, e.g. `<run_id>/artifacts/model.pkl`) and initiate a multipart upload against `/mlflow-artifacts/mpu/*` targeting that path; the missing resource-level authorization lets the write succeed even though the path belongs to another user's run. They overwrite the legitimate serialized model with a malicious pickle embedding a reverse-shell payload. When a CI/CD deployment job, a serving process, or a teammate subsequently loads that artifact as a trusted model, Python's pickle deserialization executes the payload and hands the attacker code execution inside the victim's ML infrastructure.

Weaknesses (CWE)

CWE-1220 Insufficient Granularity of Access Control Primary CWE-862 Missing Authorization Primary CWE-862 Missing Authorization

CWE-1220 — Insufficient Granularity of Access Control: The product implements access controls via a policy or other feature with the intention to disable or restrict accesses (reads and/or writes) to assets in a system from untrusted agents. However, implemented access controls lack required granularity, which renders the control policy too broad because it allows accesses from unauthorized agents to the security-sensitive assets.

[Architecture and Design, Implementation, Testing] Access-control-policy protections must be reviewed for design inconsistency and common weaknesses. Access-control-policy definition and programming flow must be tested in pre-silicon, post-silicon testing.

Source: MITRE CWE corpus.