CVE-2026-8147: MLflow auth bypass — HIGH

CISO Take

MLflow's trace API — used to log and inspect LLM/agent interactions — fails to enforce experiment-level authorization: because the `_before_request` handler never registers validators for trace endpoints, any authenticated user can read, modify, or delete traces belonging to experiments they have no permission to access. With 655 downstream dependents and a package risk score of 81/100, MLflow sits at the center of many teams' ML/LLM observability stacks, so a single shared multi-tenant instance can expose one team's prompts, model outputs, and evaluation data to every other authenticated user on the server. There's no CVSS score, EPSS data, CISA KEV listing, or public exploit/scanner yet, so this isn't a drive-by internet threat — but it's a trivial horizontal-privilege-escalation bug for anyone who already has an account, and deleting traces doubles as anti-forensics against your audit trail. Patch to MLflow 3.14.0 immediately on any multi-tenant/shared instance; until then, restrict trace API paths via reverse-proxy ACLs per experiment and review trace read/delete logs for cross-experiment access from low-privilege accounts.

Sources: NVD GitHub Advisory OpenSSF ATLAS

What is the risk?

Exploitability is high for anyone with any valid MLflow account — the bug requires no AI/ML expertise, no adversarial crafting, and no public exploit tooling: it's a straightforward broken-access-control (CWE-284) flaw where a missing authorization check lets a legitimate-but-unprivileged session touch resources it shouldn't. No CVSS/EPSS/KEV data is published yet, so quantified urgency is unavailable, and there's no evidence of in-the-wild exploitation or a Nuclei template — but the bar to exploit is a valid login, not a zero-day. Impact is high wherever MLflow runs multi-tenant with auth enabled: unauthorized read exposes potentially sensitive LLM/agent trace data (prompts, completions, tool calls), unauthorized delete destroys audit evidence, and unauthorized modification can corrupt tracing data used for debugging or compliance. Overall: treat as high-priority for any org running shared MLflow deployments with experiment-level ACLs, even without a formal severity score.

How does the attack unfold?

Initial Access

Attacker obtains a valid but low-privilege MLflow account scoped to their own experiment on a shared multi-tenant server.

AML.T0012

Discovery

Attacker enumerates or guesses experiment/trace IDs belonging to other teams via the MLflow UI or API.

AML.T0007

Exploitation

Attacker calls trace API endpoints for the foreign experiment; the missing `_before_request` authorization validator lets the request proceed unchecked.

AML.T0049

Impact

Attacker reads sensitive LLM/agent trace data or deletes/modifies traces, exposing data and destroying the audit trail.

AML.T0025

Initial Access

Attacker obtains a valid but low-privilege MLflow account scoped to their own experiment on a shared multi-tenant server.

AML.T0012

Discovery

Attacker enumerates or guesses experiment/trace IDs belonging to other teams via the MLflow UI or API.

AML.T0007

Exploitation

Attacker calls trace API endpoints for the foreign experiment; the missing `_before_request` authorization validator lets the request proceed unchecked.

AML.T0049

Impact

Attacker reads sensitive LLM/agent trace data or deletes/modifies traces, exposing data and destroying the audit trail.

AML.T0025

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
MLflow	pip	>= 2.14.0rc0, < 3.13.0rc0	`3.13.0rc0`
27.5K OpenSSF 5.6 683 dependents Pushed 2d ago 36% patched ~70d to patch Full package profile →
MLflow	pip	—	No patch
27.5K OpenSSF 5.6 683 dependents Pushed 2d ago 36% patched ~70d to patch Full package profile →

How severe is it?

CVSS 3.1

8.1 / 10

EPSS

0.4%

chance of exploitation in 30 days

Higher than 31% of all CVEs

Source: EPSS v3 — FIRST.org

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 Network

AC Low

PR Low

UI None

S Unchanged

C High

I High

A None

What should I do?

1 step

1) Upgrade to MLflow >=3.14.0, which adds authorization validators to the trace API endpoints. 2) Until patched, do not rely solely on MLflow's experiment-level ACLs for isolation — front trace API routes with a reverse proxy enforcing per-experiment path-based access control, or isolate tenants into separate MLflow server instances. 3) Audit MLflow access logs for trace-related requests (/api/2.0/mlflow/traces/* and similar) from users without an explicit role on the target experiment. 4) Check for unexpected trace deletions or modifications as an indicator of prior exploitation, since deletion doubles as anti-forensics. 5) Track the referenced GitHub commit (f9b1eb5) and huntr advisory for patch details and confirm the fix version in your deployment images before considering this closed.

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?

Auth Bypass Data Leakage Framework API AML.T0025 - Exfiltration via Cyber Means AML.T0035 - AI Artifact Collection

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 12 - Record-keeping

ISO 42001

A.6.2.6 - Data management for AI systems

NIST AI RMF

GOVERN-1.5 - Accountability and audit mechanisms

OWASP LLM Top 10

LLM06:2025 - Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2026-8147?

MLflow's trace API — used to log and inspect LLM/agent interactions — fails to enforce experiment-level authorization: because the `_before_request` handler never registers validators for trace endpoints, any authenticated user can read, modify, or delete traces belonging to experiments they have no permission to access. With 655 downstream dependents and a package risk score of 81/100, MLflow sits at the center of many teams' ML/LLM observability stacks, so a single shared multi-tenant instance can expose one team's prompts, model outputs, and evaluation data to every other authenticated user on the server. There's no CVSS score, EPSS data, CISA KEV listing, or public exploit/scanner yet, so this isn't a drive-by internet threat — but it's a trivial horizontal-privilege-escalation bug for anyone who already has an account, and deleting traces doubles as anti-forensics against your audit trail. Patch to MLflow 3.14.0 immediately on any multi-tenant/shared instance; until then, restrict trace API paths via reverse-proxy ACLs per experiment and review trace read/delete logs for cross-experiment access from low-privilege accounts.

Is CVE-2026-8147 actively exploited?

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

How to fix CVE-2026-8147?

1) Upgrade to MLflow >=3.14.0, which adds authorization validators to the trace API endpoints. 2) Until patched, do not rely solely on MLflow's experiment-level ACLs for isolation — front trace API routes with a reverse proxy enforcing per-experiment path-based access control, or isolate tenants into separate MLflow server instances. 3) Audit MLflow access logs for trace-related requests (`/api/2.0/mlflow/traces/*` and similar) from users without an explicit role on the target experiment. 4) Check for unexpected trace deletions or modifications as an indicator of prior exploitation, since deletion doubles as anti-forensics. 5) Track the referenced GitHub commit (f9b1eb5) and huntr advisory for patch details and confirm the fix version in your deployment images before considering this closed.

What systems are affected by CVE-2026-8147?

This vulnerability affects the following AI/ML architecture patterns: LLM/agent observability & tracing, MLOps experiment tracking platforms, multi-tenant ML platforms, agent frameworks (traced via MLflow).

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

CVE-2026-8147 has a CVSS v3.1 base score of 8.1 (HIGH). The EPSS exploitation probability is 0.38%.

What is the AI security impact?

Affected AI Architectures

LLM/agent observability & tracingMLOps experiment tracking platformsmulti-tenant ML platformsagent frameworks (traced via MLflow)

MITRE ATLAS Techniques

AML.T0025 Exfiltration via Cyber Means

AML.T0035 AI Artifact Collection

Compliance Controls Affected

EU AI Act: Article 12

ISO 42001: A.6.2.6

NIST AI RMF: GOVERN-1.5

OWASP LLM Top 10: LLM06:2025

What are the technical details?

Original Advisory

In MLflow versions prior to 3.14.0, when running with authentication enabled, the trace API endpoints lack proper authorization validators. This allows any authenticated user to bypass experiment-level authorization controls on all trace operations, including reading, deleting, and modifying traces on experiments they do not have permission to access. The issue arises from the `_before_request` handler, which does not register authorization validators for trace endpoints, resulting in requests proceeding without validation. This vulnerability can expose sensitive data, destroy audit logs, and allow unauthorized modifications.

Exploitation Scenario

A contractor or another business unit is granted a low-privilege MLflow account scoped only to their own experiment on a shared tracking server. Knowing (or guessing) that experiment IDs are sequential or discoverable via the UI/API, they issue authenticated requests to the trace endpoints for a different experiment ID belonging to another team — e.g. one running production LLM agent evaluations. Because `_before_request` never registers an authorization validator for trace routes, the request is processed without any experiment-membership check, letting the attacker read sensitive prompts/completions logged during that team's LLM development, or issue delete calls to wipe the trace history entirely — destroying the audit trail an incident responder or auditor would later need.

Weaknesses (CWE)

CWE-284 Improper Access Control Primary CWE-284 Improper Access Control CWE-284 Improper Access Control

CWE-284 — Improper Access Control: The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.

[Architecture and Design, Operation] Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
[Architecture and Design] Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.

Source: MITRE CWE corpus.