CVE-2026-8147: MLflow Trace API Authorization Bypass (CVSS 8.1)

Technical summary

MLflow versions before 3.14.0 contain an authorization bypass in the trace API layer. The `_before_request` handler fails to register authorization validators for trace-related endpoints (`/api/2.0/traces/*`). This omission causes HTTP requests to proceed without experiment-level permission checks, even though the authentication framework is active. An authenticated user can exploit this by crafting API calls to read, modify, or delete traces on experiments outside their permission scope. The vulnerability affects all trace operations: GET (read), POST (create), PUT (update), and DELETE. Because the authorization layer is completely absent rather than misconfigured, the bypass applies uniformly across all experiment boundaries.

Business impact

Organizations using MLflow for collaborative machine learning face exposure of proprietary model training data, training parameters, and experiment results. Data scientists or attackers with any valid account can exfiltrate experiments belonging to other teams or projects. Audit logs and trace records—critical for compliance, reproducibility, and forensics—can be deleted, destroying evidence of model decisions or data processing. Unauthorized modifications to trace metadata could corrupt experiment integrity or mislead stakeholders about model performance and lineage. In regulated industries (finance, healthcare, automotive), this creates compliance violations and accountability gaps.

Affected systems

All MLflow deployments running versions 3.13.x and earlier with authentication enabled are vulnerable. The trace API endpoints are core MLflow functionality used by the MLflow SDK and web UI, so any MLflow instance accepting remote connections is at risk. Deployments relying on network isolation or reverse proxy authentication may offer partial mitigation but do not resolve the underlying API-level flaw. MLflow 3.14.0 and later patch the issue by registering proper authorization validators.

Exploitability

Exploitability is moderate to high. An attacker needs a valid account with any permission level (even read-only access to one experiment), but no special privileges or multi-step social engineering. The exploit is a straightforward HTTP API call; no complex interaction patterns, race conditions, or special configurations are required. Tools like curl or Postman can demonstrate the vulnerability in seconds. The barrier to discovery is low—the trace API is documented and discoverable. However, exploitation requires network access to the MLflow instance, and most organizations restrict API access to internal networks or VPNs, which slows opportunistic attacks but does not prevent insider threats.

Remediation

Upgrade MLflow to version 3.14.0 or later immediately. The patch reinstates authorization validators for all trace endpoints, restoring experiment-level permission boundaries. No configuration changes or data migration is needed. If immediate patching is not possible, disable remote API access or restrict trace API endpoints at the reverse proxy layer using URL patterns matching `/api/2.0/traces/*`, though this is a temporary measure and not a substitute for the patch.

Patch guidance

Visit the MLflow releases page and download version 3.14.0 or the latest stable release. For pip-based installations, run `pip install --upgrade mlflow>=3.14.0`. For container deployments, update the MLflow Docker image tag to 3.14.0 or later and redeploy. Test the upgrade in a staging environment first to confirm compatibility with custom authentication plugins or reverse proxy configurations. No database migrations or service restarts beyond standard container/process replacement are required.

Detection guidance

Check your MLflow deployment version in the web UI (Settings → About) or via `mlflow --version` CLI. Query your package manager: `pip show mlflow` (pip) or check your requirements file. Audit MLflow API access logs for unusual trace endpoint requests, particularly GET/DELETE calls to `/api/2.0/traces` from users accessing experiments outside their team scope. Enable verbose logging in MLflow and monitor for trace operations by accounts with limited permissions. Network-level detection: flag any intra-service API calls to trace endpoints that bypass your authentication proxy's expected flow.

Why prioritize this

CVE-2026-8147 scores 8.1 (HIGH) because it combines high-impact consequences (data exfiltration, audit log deletion, experiment tampering) with low attack complexity and low privilege barriers. While it requires authentication, it undermines the core purpose of role-based access control in MLflow. The vulnerability is not yet listed on CISA's KEV, but the broad scope (all trace operations), easy exploitation, and upstream trust in MLflow's authorization model make it a priority for teams using MLflow in multi-user environments. Organizations with shared MLflow instances and sensitive experiment data should patch within days, not weeks.

Risk score, explained

The CVSS 3.0 score of 8.1 reflects: (1) Network attack vector—the API is remote-accessible; (2) Low attack complexity—no special conditions or race conditions; (3) Low privilege requirement—any authenticated user qualifies; (4) No user interaction needed; (5) High confidentiality impact—all traces can be read; (6) High integrity impact—traces can be deleted or modified; (7) No availability impact—the system remains operational. The score does not assume CVSS 3.1 qualifiers, so actual risk may vary based on your attack surface (is MLflow internet-facing? how many user accounts exist?). If MLflow is internal-only and accounts are tightly controlled, practical risk is lower; if it's shared across many teams or externally accessible, risk approaches critical.

Frequently asked questions