CVE-2025-14279

What it actually does

MLflow REST server versions up to and including 3.4.0 do not adequately validate the HTTP Origin header, enabling DNS rebinding attacks against MLflow endpoints reachable from a victim's browser. A malicious website can cause the browser to send authenticated or network-local requests to the MLflow REST API while bypassing normal Same-Origin Policy protections. Successful exploitation can allow unauthenticated cross-origin REST calls to query, modify, or delete MLflow experiment metadata and related tracking data. The flaw is network-exploitable with low attack complexity but requires user interaction, such as a user visiting an attacker-controlled page from a browser that can reach the MLflow server.

Why it matters to the business

Organizations using vulnerable MLflow tracking servers may face loss, alteration, or exposure of experiment metadata, model development history, parameters, metrics, artifacts references, and operational ML workflow data. This can disrupt machine learning development, undermine experiment reproducibility, corrupt model governance records, and expose sensitive information about datasets, models, internal projects, or infrastructure. The issue is not currently listed in CISA KEV, has low EPSS probability, and has no reported mature public exploitation in the provided data, but the CVSS score is high because exploitation can affect confidentiality and integrity without attacker credentials if a user with network access is lured to a malicious site.

How an attack unfolds

An attacker first identifies or assumes that an MLflow REST server is reachable from a target user's browser, such as on localhost, an internal hostname, a private IP address, or a development network. The attacker hosts a malicious web page on a domain they control and uses DNS rebinding so that the domain initially resolves to the attacker's server and later resolves to the MLflow server address. When the victim visits the malicious page, browser-based JavaScript issues requests to MLflow REST endpoints through the rebound domain. Because vulnerable MLflow versions do not properly validate the Origin header, the server accepts these cross-origin requests. The attacker can then enumerate experiments, retrieve metadata, update experiment fields or tags, and delete experiments using MLflow REST API calls, potentially exfiltrating or corrupting tracking data without directly authenticating to MLflow.

How to fix it

Upgrade MLflow to version 3.5.0 or later. For source-based deployments, ensure the fix commit b0ffd289e9b0d0cc32c9e3a9b9f3843ae83dbec3 or a later commit is present. Rebuild and redeploy containers, virtual environments, and packaged applications that include MLflow versions 3.4.0 or earlier. As compensating controls, restrict MLflow access to trusted networks, require authentication in front of MLflow, place MLflow behind a reverse proxy that enforces strict Host and Origin allowlists, block cross-origin requests from untrusted origins, and avoid exposing unauthenticated MLflow tracking servers to user workstations or the public internet. Where reverse proxies are used, validate that they do not pass requests with unexpected Host, Origin, or Referer headers to MLflow.

How to confirm the fix worked

Confirm the installed MLflow version is 3.5.0 or later using package, image, or runtime checks such as `mlflow --version`, `pip show mlflow`, dependency lockfiles, container image manifests, or application software bills of materials. For source deployments, verify that commit b0ffd289e9b0d0cc32c9e3a9b9f3843ae83dbec3 or a later fixed revision is included. Validate exposure by identifying running MLflow servers and testing whether REST endpoints are reachable from untrusted networks or ordinary user browsers. Confirm the fix or mitigation by sending REST API requests with an untrusted Origin header, unexpected Host header, and cross-site browser-style headers; fixed or properly proxied deployments should reject or block unauthorized cross-origin requests. Review reverse proxy and MLflow access logs to ensure legitimate functionality still works only from approved origins and hosts.

Typical attack path

1. Attacker prepares a malicious website and DNS records capable of rebinding to an internal, private, or localhost address where MLflow may be reachable.
2. Victim with browser access to the MLflow server visits the attacker-controlled website.
3. The attacker-controlled page uses JavaScript to issue REST API requests after DNS resolution changes to the MLflow server address.
4. The vulnerable MLflow REST server accepts the requests because Origin validation is missing or insufficient.
5. Attacker enumerates MLflow experiments and related tracking metadata using REST endpoints.
6. Attacker updates, manipulates, or deletes experiments through affected REST API calls.
7. Attacker exfiltrates obtained MLflow data or causes integrity loss and workflow disruption.

How to detect it

To determine whether exploitation already occurred, review MLflow server logs, reverse proxy logs, WAF logs, endpoint browser telemetry, DNS logs, and backend tracking-store audit records. Look for REST API requests to MLflow experiment endpoints with external or unexpected Origin or Referer headers, browser user agents, cross-site fetch headers, unusual Host values, or requests originating from ordinary user workstations rather than expected automation or service accounts. Pay particular attention to destructive or modifying endpoints such as experiment delete, update, restore, and tag-setting operations. DNS rebinding activity may appear as rapid DNS changes for the same attacker-controlled domain from a public IP address to a private, localhost, or internal address, followed by browser-originated requests to MLflow. In MLflow data stores, investigate unexpected experiment lifecycle stage changes, deleted experiments, renamed experiments, modified tags, or high-volume experiment enumeration. Because no specific attacker infrastructure is provided, detection should be behavior-based and focused on cross-origin browser requests to sensitive MLflow REST endpoints.

• /api/2.0/mlflow/experiments/delete
• /api/2.0/mlflow/experiments/update
• /api/2.0/mlflow/experiments/search
• /api/2.0/mlflow/experiments/get
• /api/2.0/mlflow/experiments/create
• /api/2.0/mlflow/experiments/restore
• /api/2.0/mlflow/experiments/set-experiment-tag
• Sec-Fetch-Site: cross-site
• Origin: null
• Host: localhost
• Host: 127.0.0.1
• Host: 0.0.0.0
• User-Agent: Mozilla/5.0

What your security team should do

• Inventory all MLflow tracking server deployments, including developer workstations, notebooks, containers, CI/CD environments, and internal ML platforms.
• Prioritize upgrading MLflow versions 3.4.0 and earlier to 3.5.0 or later, especially systems reachable from browsers, shared networks, or unauthenticated users.
• Add reverse proxy protections that enforce allowed Host and Origin values before requests reach MLflow.
• Require authentication and network access controls for MLflow; do not rely on network locality alone as a security boundary.
• Search logs for suspicious cross-origin MLflow REST calls, especially experiment deletion or update actions paired with external Origin or Referer values.
• If suspicious activity is found, preserve MLflow access logs, reverse proxy logs, experiment history, backend database snapshots, and artifact-store access logs before remediation overwrites evidence.
• Review MLflow experiment records for unexpected deletions, renamed experiments, modified tags, unusual search activity, or changes made outside normal user workflows.
• Educate users with access to internal MLflow servers not to browse untrusted links from the same browser context or workstation used for internal development services.