MLflow SSRF Flaw (CVE-2026-64849) Hands Attackers Your Cloud Credentials

Red | Vulnerability
MLflow SSRF Flaw (CVE-2026-64849) Hands Attackers Your Cloud Credentials

Summary

A critical server-side request forgery (SSRF) vulnerability, tracked as CVE-2026-64849, has been found in MLflow, the widely used open-source platform that machine learning and data engineering teams rely on to track experiments, package code, and deploy models. The flaw lives in an unauthenticated webhook-testing endpoint and affects every version of MLflow before 3.15.0.

What makes this MLflow SSRF vulnerability especially dangerous is that the server hands the full response back to the attacker, turning a normally "blind" SSRF into a tool that can read sensitive data directly. Security researchers observed real-world attacks against internet-exposed MLflow servers within hours of public disclosure, with attackers racing to harvest cloud credentials and deployment tokens. The issue has been fixed in MLflow 3.15.0.

CVENameAffected ProductZero-DayCISA KEVPatch
CVE-2026-64849MLflow Unauthenticated Server-Side Request Forgery VulnerabilityMLflow (mlflow)Available

Vulnerability Details

01

CVE-2026-64849 is a server-side request forgery flaw affecting all MLflow releases before 3.15.0. It sits in the model-registry webhooks feature, specifically the unauthenticated POST /api/2.0/mlflow/webhooks/{id}/test endpoint. A default Tracking Server (mlflow server) runs without authentication on a local SQLite backend, so this webhook API is often exposed to untrusted traffic straight out of the box.

02

The root cause is an incomplete security check. The _validate_webhook_url() helper added in version 3.10.0 blocks private and cloud metadata addresses, but only inspects the first URL. The delivery code in mlflow/webhooks/delivery.py then follows HTTP redirects and re-resolves the hostname without pinning the validated address. An attacker can host a public URL that passes the initial check and returns an HTTP 302 redirect to a link-local metadata service or internal loopback address, and because the hostname is re-resolved after the check, the flaw is also open to DNS-rebinding attacks.

03

What turns this MLflow flaw from a typical SSRF into a full-read primitive is the test endpoint's behavior: instead of just firing the webhook, it reflects the upstream HTTP status and response body to the caller. The attacker therefore receives the actual contents of whatever internal or cloud resource was reached. On AWS, Azure, and Google Cloud, this exposes temporary IAM credentials, OAuth tokens, and environment configuration from the metadata address at 169.254.169.254, along with internal microservices and loopback admin consoles that trust the host.

04

Active exploitation of CVE-2026-64849 is not theoretical. A honeypot network reported attackers targeting internet-exposed MLflow instances within hours of the CVE being assigned. A public proof-of-concept is also available, including a confirmed reproduction against MLflow 3.13.0, and the flaw was independently disclosed in public GitHub issue #24179. The vulnerability is fixed in MLflow 3.15.0, and defenders should assume opportunistic mass exploitation is ongoing.

Affected Product Matrix
CVE IDAffected ProductsAffected CPECWE ID
CVE-2026-64849MLflow (Before 3.15.0)cpe:2.3:a:mlflow:mlflow:*:*:*:*:*:*:*:*CWE-918

Recommendations

STEP 01
Upgrade MLflow Immediately

Update every MLflow Tracking Server to version 3.15.0 or later without delay. This release fixes the redirect-following and DNS-rebinding weaknesses in the webhook delivery logic and is the only complete remedy for CVE-2026-64849.

STEP 02
Rotate Potentially Exposed Credentials

Because patching does not undo any theft that already occurred, assume exposure on any internet-facing MLflow server and rotate all cloud IAM keys, OAuth tokens, and API secrets tied to the host instance, even after upgrading.

STEP 03
Audit Access Logs for Abuse

Review server access logs for requests directed at /webhooks/*/test, paying special attention to any that predate your upgrade. Requests to this path from unexpected sources are a strong signal of attempted or successful exploitation.

STEP 04
Isolate MLflow Behind Authentication

Place Tracking Servers behind an identity-aware proxy or authentication layer and remove them from direct public exposure. Default MLflow deployments ship without authentication.


Potential MITRE ATT&CK TTPs

T1595.002
ReconnaissanceVulnerability Scanning
T1190
Initial AccessExploit Public-Facing Application
T1552.005
Credential AccessUnsecured Credentials: Cloud Instance Metadata API
T1588.006
Resource DevelopmentObtain Capabilities: Vulnerabilities

What Next?

At Hive Pro, it is our mission to detect the most likely threats to your organization and to help you prevent them from happening.

Reduce real exposure. Not just vulnerability volume.