CVE-2026-13484: missing authz — HIGH

CISO Take

A vulnerability in MLflow's experiment-scoped Label Schema CRUD API allows a low-privileged authenticated user to read, create, or modify label schema data outside their assigned experiment scope, because the endpoints lack proper authorization checks (CWE-862/CWE-863). The CVSS 8.8 score reflects full confidentiality, integrity, and availability impact within the affected component, but the EPSS score of 0.26% (top 82nd percentile of scored CVEs) and "difficult" real-world exploitability rating indicate low near-term exploitation pressure, and there is no public PoC, Nuclei template, or CISA KEV listing. Critically, the maintainer's own GitHub reply states "the labeling schema PR has not been merged yet" and "auth handlers will be added before the release" — meaning this feature may still be in development/pre-release code rather than shipped in a stable MLflow version, which materially limits current production exposure. CISOs running MLflow tracking servers should confirm whether their deployed version includes the label schema feature at all before treating this as urgent; if it is present, restrict tracking-server network exposure, enforce authentication on all experiment-management endpoints, and monitor MLflow release notes/changelogs for the patched auth handlers before upgrading.

Sources: NVD EPSS GitHub Advisory ATLAS

What is the risk?

Moderate-to-low near-term risk. The flaw is a classic missing/incorrect authorization bug (broken access control) rather than a novel AI-specific attack, but it sits on an ML experiment-tracking system that often holds sensitive metadata (experiment names, labels, tags used for governance/compliance classification). Mitigating factors: EPSS is very low (0.26%), no public exploit or scanner signature exists, the vendor characterizes exploitation as "difficult," and — most importantly — the underlying labeling-schema feature may not yet be merged/released, meaning many production MLflow instances are likely unaffected today. Organizations should verify their MLflow version/build before prioritizing remediation.

How does the attack unfold?

Initial Access

Attacker authenticates to a shared MLflow tracking server with valid but low-privileged credentials.

Exploitation

Attacker invokes the Experiment-scoped Label Schema CRUD API directly against experiments outside their authorized scope, exploiting missing authorization checks.

AML.T0007

Impact

Attacker reads, tampers with, or deletes experiment label schema data, corrupting ML governance metadata or undermining trust in experiment/label integrity.

AML.T0059

Initial Access

Attacker authenticates to a shared MLflow tracking server with valid but low-privileged credentials.

Exploitation

Attacker invokes the Experiment-scoped Label Schema CRUD API directly against experiments outside their authorized scope, exploiting missing authorization checks.

AML.T0007

Impact

Attacker reads, tampers with, or deletes experiment label schema data, corrupting ML governance metadata or undermining trust in experiment/label integrity.

AML.T0059

How severe is it?

CVSS 3.1

8.8 / 10

EPSS

0.5%

chance of exploitation in 30 days

Higher than 41% 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 None

S Unchanged

C High

I High

A High

What should I do?

1 step

1) Verify whether your deployed MLflow version/build actually includes the Label Schema CRUD feature — per the vendor's GitHub response, it may not yet be released, in which case no action is needed beyond monitoring. 2) If present, restrict network access to the MLflow tracking server to trusted internal networks/VPN only — do not expose it directly to the internet. 3) Enforce strict role-based access control at the reverse-proxy or auth-gateway layer for all /api/2.0/mlflow/* label/experiment management endpoints as defense-in-depth until an official patch/auth-handler fix ships. 4) Monitor MLflow release notes and the linked GitHub issue (mlflow/mlflow#23608) for the promised auth-handler fix and upgrade promptly once available. 5) Detection: audit MLflow access logs for label schema CRUD calls (create/update/delete) originating from users without corresponding experiment ownership/permissions.

What does CISA's SSVC say?

Decision Track*

Exploitation poc

Automatable No

Technical Impact partial

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

How is it classified?

Auth Bypass API Framework AML.T0007 - Discover AI Artifacts AML.T0059 - Erode Dataset Integrity

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.2 - AI system access controls

NIST AI RMF

GOVERN 1.5 / MANAGE 4.1 - Access control and risk monitoring for AI system components

Frequently Asked Questions

What is CVE-2026-13484?

A vulnerability in MLflow's experiment-scoped Label Schema CRUD API allows a low-privileged authenticated user to read, create, or modify label schema data outside their assigned experiment scope, because the endpoints lack proper authorization checks (CWE-862/CWE-863). The CVSS 8.8 score reflects full confidentiality, integrity, and availability impact within the affected component, but the EPSS score of 0.26% (top 82nd percentile of scored CVEs) and "difficult" real-world exploitability rating indicate low near-term exploitation pressure, and there is no public PoC, Nuclei template, or CISA KEV listing. Critically, the maintainer's own GitHub reply states "the labeling schema PR has not been merged yet" and "auth handlers will be added before the release" — meaning this feature may still be in development/pre-release code rather than shipped in a stable MLflow version, which materially limits current production exposure. CISOs running MLflow tracking servers should confirm whether their deployed version includes the label schema feature at all before treating this as urgent; if it is present, restrict tracking-server network exposure, enforce authentication on all experiment-management endpoints, and monitor MLflow release notes/changelogs for the patched auth handlers before upgrading.

Is CVE-2026-13484 actively exploited?

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

How to fix CVE-2026-13484?

1) Verify whether your deployed MLflow version/build actually includes the Label Schema CRUD feature — per the vendor's GitHub response, it may not yet be released, in which case no action is needed beyond monitoring. 2) If present, restrict network access to the MLflow tracking server to trusted internal networks/VPN only — do not expose it directly to the internet. 3) Enforce strict role-based access control at the reverse-proxy or auth-gateway layer for all `/api/2.0/mlflow/*` label/experiment management endpoints as defense-in-depth until an official patch/auth-handler fix ships. 4) Monitor MLflow release notes and the linked GitHub issue (mlflow/mlflow#23608) for the promised auth-handler fix and upgrade promptly once available. 5) Detection: audit MLflow access logs for label schema CRUD calls (create/update/delete) originating from users without corresponding experiment ownership/permissions.

What systems are affected by CVE-2026-13484?

This vulnerability affects the following AI/ML architecture patterns: MLOps / experiment tracking pipelines, model governance and metadata management.

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

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

What is the AI security impact?

Affected AI Architectures

MLOps / experiment tracking pipelinesmodel governance and metadata management

MITRE ATLAS Techniques

AML.T0007 Discover AI Artifacts

AML.T0059 Erode Dataset Integrity

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2.2

NIST AI RMF: GOVERN 1.5 / MANAGE 4.1

What are the technical details?

Original Advisory

A vulnerability has been found in MLflow up to 4666cffc7912ea606d592fc38d6a75e2935f65e7. The impacted element is an unknown function of the component Experiment-scoped Label Schema CRUD API. Such manipulation leads to missing authorization. It is possible to launch the attack remotely. A high complexity level is associated with this attack. The exploitability is regarded as difficult. The exploit has been disclosed to the public and may be used. A reply to the GitHub issue explains, that "[t]he labeling schema PR has not been merged yet. The auth handlers will be added before the release."

Exploitation Scenario

An attacker who has obtained low-privileged, legitimate credentials to a shared MLflow tracking server (e.g., a contractor, junior data scientist, or compromised low-tier account) calls the experiment-scoped Label Schema CRUD API directly against experiments they are not authorized to manage. Because the API lacks proper authorization enforcement, the request succeeds, allowing the attacker to view, modify, or delete labeling schema entries tied to other teams' or projects' experiments. This could be used to sabotage a competing team's model governance metadata, mask malicious model behavior by relabeling compliance tags, or simply exfiltrate sensitive experiment classification data across organizational boundaries within a shared MLflow deployment.

Weaknesses (CWE)

CWE-862 Missing Authorization Primary CWE-863 Incorrect Authorization Primary CWE-862 Missing Authorization CWE-863 Incorrect Authorization

CWE-862 — Missing Authorization: The product does not perform an authorization check when an actor attempts to access a resource or perform an action.

[Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
[Architecture and Design] Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Source: MITRE CWE corpus.