CVE-2025-14279: MLflow DNS Rebinding Attack Enables Silent ML Experiment Takeover

CVE: CVE-2025-14279
Affected Product: MLflow Tracking Server (versions up to 3.4.0)
CVSSv3 Score: 8.1 (High)
Severity: High
Exploitability: The flaw can be triggered remotely via a victim’s browser using a DNS rebinding technique. No authentication is needed if the victim’s browser is connected to the MLflow server.
Exploit Availability: There is no widely circulated public PoC hosted by a trusted third party, but the exploitation pattern can be constructed based on known DNS rebinding techniques and web API behavior.
Official Patch/Upgrade: Upgrade full MLflow server to the fixed release — MLflow 3.5.0.

What This Vulnerability Really Is

MLflow is a tool used by machine learning teams to track experiments, parameters, metrics, artifacts, and models. Most teams run an MLflow server where developers or automated systems interact via a browser or REST API.

The vulnerability in question happens because MLflow did not correctly check where a request is coming from before processing it. Normally a web application should validate the Origin and Host of an incoming request, especially if it can change data.

In versions before 3.5.0, MLflow’s web interface and REST API would accept cross-origin requests without strong enough verification. That means a malicious webpage could trick a developer’s browser into talking to the MLflow server as if it were a trusted client. This attack is done using DNS rebinding, which manipulates how a domain resolves so that a browser believes it is talking to a trusted host while actually sending traffic to an internal system.

Once that trust boundary is broken, the attacker can use the user’s browser to issue API calls to the MLflow server — listing experiments, creating or modifying experiments, deleting experiments, or tampering with metadata stored in the system.

How This Can Be Exploited – Step-by-Step

1. Understanding DNS Rebinding

DNS rebinding is a web attack technique. The attacker sets up a domain so that:

At first, the domain resolves to the attacker’s web server.
After a few seconds, DNS answers change so the same domain resolves to an internal IP (for example, how localhost or internal services are addressed).

From the browser’s point of view, the domain has not changed. The browser enforces same-origin by domain name, not by IP. So after rebinding, JavaScript loaded from the attacker’s page can send requests to internal services using the victim’s browser.

2. Targeting MLflow

MLflow’s REST API and UI endpoints are typically on a known host/IP — for example, localhost:5000 or an internal host in a corporate network. Because MLflow lacked robust origin validation, once the browser thinks it is talking to the same origin it trusts, it will happily send API requests.

So the malicious website:

Gets a developer to visit a page.
Performs DNS rebinding so the attacker’s domain now routes to the MLflow host.
Uses JavaScript in the page to send normal REST API calls (like experiment search, creation, deletion) through the browser to the MLflow server.

3. Typical Actions an Attacker Could Take

If exploitation succeeds, the attacker (through the victim’s browser) could:

Read all experiments and metadata.
Delete experiments or runs.
Modify experiment parameters and metrics.
Corrupt stored artifacts or tracking data.
Trigger server actions that normally require a trusted client.

There is no code execution on the server’s host machine itself — but the integrity and confidentiality of the MLflow data is compromised.

Is There a Public Proof of Concept (PoC)?

There is no widely accepted public PoC script hosted on major public exploit repositories. However, the exploitation technique is well known among security professionals, and a functioning PoC can be written by someone familiar with DNS rebinding and browser APIs.

For educational purposes, attackers typically write a malicious HTML page that:

Loads in the victim’s browser.
Uses JavaScript to repeatedly send API calls to the MLflow server once DNS rebinding resolves the controlled domain to the internal MLflow host.

You should never run such code on systems you do not own or operate — but this is how the flaw would be tested in a controlled environment.

How to Detect Attempted Abuse or Exploitation

To spot potential exploitation or scanning attempts you need to adjust monitoring on the services that serve MLflow and the logs that record API traffic.

Log Sources to Watch

MLflow Access/Application Logs
- Look for REST API calls with unusual referers or external Origin headers.
- Monitor for experiment deletion or creation calls originating from browser UA strings rather than expected service automation.
Reverse Proxy / Web Server Logs (e.g., NGINX, Apache)
- Look at access logs for calls from a browser user agent but with originating domains that are not trusted.
- Watch for mismatches between Host and Origin.
Firewall / Network Logs
- Detect unusual DNS patterns where the same domain starts resolving to internal addresses shortly after external resolution.
- Identify inbound browser traffic that is inconsistent with regular application use.
Browser Security Telemetry
- Modern enterprise browser logs can show tab navigations to suspicious domains while simultaneously hitting internal APIs.

Anomalies That Suggest Exploitation

A large number of REST API calls coming from a single browser session where the Origin header does not match your known trusted hostnames.
API calls like /api/2.0/mlflow/experiments/delete that are coming from sources you wouldn’t expect (for example, ebedded browsers, user workstations, not automation services).
Sudden spike in experiment modifications or data loss events without obvious internal triggers.

Detection Rules

These example queries/rules can be adapted to your SIEM/WAF tool.

Example SIEM Query – External Origin Header

search index=mlflow sourcetype=access_logs
| where request_url like "/api/2.0/mlflow/%"
| where Origin != "" AND Origin NOT LIKE "https://trusted-domain%"
| stats count by client_ip, Origin, request_url, user_agent
| sort - count

This looks for API calls where the Origin header is present but not one of your known trusted site origins.

WAF Rule Idea (Pseudo)

Block or alert on requests where:

Origin exists
Origin is not in your allowed list
Target path starts with /api/2.0/mlflow/

This helps stop requests before they hit MLflow.

Sigma Rule Example Concept

title: Suspicious MLflow Access With External Origin
description: Detects possible DNS rebinding exploitation where MLflow API calls are made with an external origin.
logsource:
  product: web_server
detection:
  selection:
    request_path: "/api/2.0/mlflow/"
    Origin|contains: "http"
  condition: selection AND NOT Origin in ("https://your-mlflow-host")
level: high

How to Confirm a Suspected Exploit

Check the timestamps for the suspicious requests.
Review DNS logs to see if any rebind-like patterns (rapid DNS answer changes) occurred.
Compare against expected API usage patterns (normal CLI/automation vs. browser patterns).
Validate that the Origin header did not belong to an allowed host.
Verify that the user’s browser visited unexpected pages at the same time.

If these align, it likely indicates exploitation attempts.

What You Must Do — Immediate Action Plan

1. Patch / Upgrade

The only full fix is to upgrade your MLflow installation to the patched version (MLflow 3.5.0 or newer). This version introduces stricter validation of origin and host headers to block DNS rebinding.
Upgrade link (official): https://mlflow.org/releases

Upgrading not only fixes this issue but ensures future updates are easier to manage.

2. Restrict Access

While upgrading, place MLflow behind:

A reverse proxy that enforces strict allowed hosts.
Firewall rules blocking public access if not necessary.
Authentication layers (OAuth, corporate SSO).

3. Harden

Only allow trusted networks and clients.
Enforce HTTPS and strong TLS settings.
Use a WAF and define allow-lists for valid origins.

4. Monitor

Deploy the detection rules above. Watch for:

Unusual cross-origin calls.
API actions that modify or delete experiments outside normal patterns.

MITRE / CWE Context

This vulnerability falls into the category where a service fails to validate the source of web requests properly. This is often referred to as an Origin Validation Error, where browsers enforce cross-origin restrictions but the server trusts too much. In MITRE terms, it is correlated with weaknesses in recognizing where requests truly originate, which attackers can exploit to bypass normal access controls.

Final Takeaways

The vulnerability lets a malicious website trick a developer’s browser into sending API calls to an internal MLflow server.
This can lead to reading, modifying, deleting experiment data.
No public exploit script may be widely available yet, but the mechanism is well understood and can be crafted.
Detection requires careful logging and anomaly spotting in API access patterns.
The only complete fix is upgrading to MLflow 3.5.0.
While planning the upgrade, restrict access, enforce proxies, and set up SIEM/WAF detection.