CVE-2026-69146: MLflow: missing authZ lets users forge dataset lineage
GHSA-3p64-6gvh-82v5 MEDIUM CISA: TRACK*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.
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?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| MLflow | npm | < 3.15.0 | 3.15.0 |
Do you use MLflow? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 step-
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?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
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
MITRE ATLAS Techniques
AML.T0012 Valid Accounts AML.T0059 Erode Dataset Integrity Compliance Controls Affected
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
Primary
CWE-862 Missing Authorization
Primary
CWE-862 Missing 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.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N References
Timeline
Related Vulnerabilities
CVE-2025-15379 10.0 MLflow: RCE via unsanitized model dependency specs
Same package: mlflow CVE-2023-3765 10.0 MLflow: path traversal allows arbitrary file read
Same package: mlflow CVE-2026-2635 9.8 mlflow: security flaw enables exploitation
Same package: mlflow CVE-2023-2780 9.8 MLflow: path traversal allows arbitrary file read/write
Same package: mlflow CVE-2023-1177 9.8 MLflow: path traversal allows arbitrary file read/write
Same package: mlflow