CVE-2026-69146: MLflow: missing authZ lets users forge dataset lineage

GHSA-3p64-6gvh-82v5 MEDIUM CISA: TRACK*
Published August 17, 2026
CISO Take

MLflow's LogInputs endpoint was never wired into the authorization middleware, so any authenticated user — regardless of permissions on a given experiment or run — can call the log-inputs API against someone else's run_id and inject fabricated dataset lineage records. This matters because MLflow's dataset_inputs metadata is exactly the kind of provenance trail teams point to when demonstrating data governance for ISO 42001 audits or EU AI Act Article 12 record-keeping obligations, and a forged entry can make a run appear to have used a dataset it never touched. With 683 downstream dependents and no privilege beyond a low-tier authenticated account required (CVSS AC:L/PR:L/UI:N), the bar to exploit is trivial, though the CVSS 6.5 rating reflects that the impact is integrity-only — no data exfiltration or service disruption results directly. There's no evidence of public exploit code, no CISA KEV listing, and no EPSS score yet, so this isn't an emergency patch, but it's a straightforward governance-integrity issue worth fixing on the normal cycle. Upgrade to MLflow 3.15.0, and in the interim audit dataset_inputs records for entries that don't match the run owner's expected data sources.

Sources: NVD GitHub Advisory ATLAS OpenSSF CISA KEV

What is the risk?

Medium risk overall. Exploitability is high in relative terms — the flaw requires only a valid low-privilege MLflow account, network access to the tracking server, and a single unauthenticated-by-design API call, with no user interaction needed. However, the CVSS vector (C:N/I:H/A:N) confirms the blast radius is confined to integrity of lineage metadata: no confidentiality breach, no availability impact, and no path to code execution or credential theft is described in the advisory. There is no public PoC, no Nuclei template, and it is absent from CISA KEV, so opportunistic mass exploitation is unlikely. The real risk is to organizations that treat MLflow's dataset_inputs as an authoritative audit trail — multi-tenant MLflow deployments with auth enabled (self-hosted, not Databricks-managed) are the ones exposed.

How does the attack unfold?

Valid low-privilege access
Attacker obtains or already holds a legitimate but low-privilege authenticated account on a shared MLflow tracking server.
AML.T0012
Authorization bypass
Attacker calls POST /api/2.0/mlflow/runs/log-inputs targeting a run_id they do not own, exploiting the missing authorization check on the LogInputs handler.
Lineage poisoning
The request succeeds and injects attacker-controlled DatasetInput records into the victim run's dataset_inputs lineage metadata.
AML.T0059
Downstream trust impact
Compliance, audit, or governance workflows that consume the run's lineage data unknowingly rely on the forged dataset provenance.

What systems are affected?

Package Ecosystem Vulnerable Range Patched
MLflow npm < 3.15.0 3.15.0
28.1K OpenSSF 5.3 691 dependents Pushed 5d ago 36% patched ~75d to patch Full package profile →

Do you use MLflow? You're affected.

How severe is it?

CVSS 3.1
6.5 / 10
EPSS
0.4%
chance of exploitation in 30 days
Higher than 31% of all CVEs
Exploitation Status
Exploit Available
Exploitation: MEDIUM
Sophistication
Trivial
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 AC PR UI S C I A
AV Network
AC Low
PR Low
UI None
S Unchanged
C None
I High
A None

What should I do?

1 step
  1. Patch to MLflow 3.15.0 or later, where LogInputs is correctly registered under BEFORE_REQUEST_HANDLERS. Until patched, restrict who can obtain authenticated accounts on the MLflow tracking server and treat any account issuance as equivalent to write access on all runs. Audit existing dataset_inputs records for DatasetInput entries that don't correlate with the expected data sources for a given run/experiment, particularly on runs owned by high-value or compliance-relevant experiments. Add monitoring/alerting on POST /api/2.0/mlflow/runs/log-inputs calls where the calling user does not match the run's owner, since this is the specific abuse pattern this CVE enables.

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 Model Poisoning Framework Training Data API AML.T0012 AML.T0059

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Article 12 - Record-keeping
ISO 42001
A.7.2 - Data for AI systems
OWASP LLM Top 10
LLM04:2025 - Data and Model Poisoning

Frequently Asked Questions

What is CVE-2026-69146?

MLflow's LogInputs endpoint was never wired into the authorization middleware, so any authenticated user — regardless of permissions on a given experiment or run — can call the log-inputs API against someone else's run_id and inject fabricated dataset lineage records. This matters because MLflow's dataset_inputs metadata is exactly the kind of provenance trail teams point to when demonstrating data governance for ISO 42001 audits or EU AI Act Article 12 record-keeping obligations, and a forged entry can make a run appear to have used a dataset it never touched. With 683 downstream dependents and no privilege beyond a low-tier authenticated account required (CVSS AC:L/PR:L/UI:N), the bar to exploit is trivial, though the CVSS 6.5 rating reflects that the impact is integrity-only — no data exfiltration or service disruption results directly. There's no evidence of public exploit code, no CISA KEV listing, and no EPSS score yet, so this isn't an emergency patch, but it's a straightforward governance-integrity issue worth fixing on the normal cycle. Upgrade to MLflow 3.15.0, and in the interim audit dataset_inputs records for entries that don't match the run owner's expected data sources.

Is CVE-2026-69146 actively exploited?

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

How to fix CVE-2026-69146?

Patch to MLflow 3.15.0 or later, where LogInputs is correctly registered under BEFORE_REQUEST_HANDLERS. Until patched, restrict who can obtain authenticated accounts on the MLflow tracking server and treat any account issuance as equivalent to write access on all runs. Audit existing dataset_inputs records for DatasetInput entries that don't correlate with the expected data sources for a given run/experiment, particularly on runs owned by high-value or compliance-relevant experiments. Add monitoring/alerting on POST /api/2.0/mlflow/runs/log-inputs calls where the calling user does not match the run's owner, since this is the specific abuse pattern this CVE enables.

What systems are affected by CVE-2026-69146?

This vulnerability affects the following AI/ML architecture patterns: training pipelines, MLOps experiment tracking, model governance/compliance pipelines.

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

CVE-2026-69146 has a CVSS v3.1 base score of 6.5 (MEDIUM). The EPSS exploitation probability is 0.39%.

What is the AI security impact?

Affected AI Architectures

training pipelinesMLOps experiment trackingmodel governance/compliance pipelines

MITRE ATLAS Techniques

AML.T0012 Valid Accounts
AML.T0059 Erode Dataset Integrity

Compliance Controls Affected

EU AI Act: Article 12
ISO 42001: A.7.2
OWASP LLM Top 10: LLM04:2025

What are the technical details?

Original Advisory

MLflow is an open source AI engineering platform for agents, large language models, and machine learning models. From 3.13.0 until 3.15.0, LogInputs is absent from BEFORE_REQUEST_HANDLERS in the mlflow/server/auth package, allowing any authenticated user to call POST /api/2.0/mlflow/runs/log-inputs for another user's run_id and inject attacker-controlled DatasetInput records into the dataset_inputs lineage metadata without UPDATE permission. This issue is fixed in version 3.15.0.

Exploitation Scenario

An organization runs a shared MLflow tracking server with the built-in auth plugin so multiple teams can log experiments under distinct accounts. A disgruntled or compromised low-privilege user — who has a valid account but no UPDATE permission on a colleague's run — crafts a direct POST request to /api/2.0/mlflow/runs/log-inputs, supplying the victim's run_id and a fabricated DatasetInput payload referencing a dataset that was never actually used (for example, one with known bias, licensing issues, or malicious provenance). Because the endpoint's authorization check is missing, the request succeeds, and the forged dataset now appears in that run's official lineage record. Weeks later, when a compliance team or auditor pulls the run's lineage to document data provenance for an ISO 42001 or EU AI Act audit, they unknowingly cite the fabricated dataset as evidence, undermining the reliability of the entire audit trail.

Weaknesses (CWE)

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.

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N

Timeline

Published
August 17, 2026
Last Modified
August 18, 2026
First Seen
August 18, 2026

Related Vulnerabilities