MLflow CVE-2026-64849: Cloud Credential Theft via Webhook SSRF

1. Basic Information

• Article Title: Unauthenticated SSRF in MLflow Webhooks
• Publisher: MLflow Security Advisory / CISA
• Publication Date: 2026-08-19
• Severity: Critical
• Original Source: MLflow Security Advisory / CISA
• Related Sources: CISA warns of hackers exploiting critical MLflow vulnerability, MLflow Vulnerability Exploited for Cloud Credential Theft
• Related Malware: None / Unidentified
• Threat Actor: None / Unidentified
• CVE: CVE-2026-64849
• Products & Technologies: MLflow Tracking Server, AWS EC2 Instance Metadata Service
• Primary Target CVE: CVE-2026-64849

2. Summary

An attack that uses unauthenticated webhook creation and testing features to bypass protections via redirects or DNS re-resolution, allowing attackers to read cloud metadata and internal services.

Reason for Severity: It reaches tracking servers in default configurations without authentication, leads to cloud IAM credential theft, and is actively exploited and added to the CISA KEV list.

3. Attack Flow

Reading Internal Information via Reflected SSRF

1. The attacker finds an externally exposed MLflow Tracking Server.
2. They use an unauthenticated API to create a webhook pointing to the attacker's public HTTPS server.
3. The public server sends a 302 redirect to cloud metadata or internal URLs.
4. MLflow checks only the original URL and accesses the redirect target without re-evaluating it.
5. The webhook test response returns the internal response body, exposing IAM role credentials and other data to the attacker.

Blind Write / DNS Rebinding

1. 307/308 redirects maintain the POST method, enabling blind writes to internal services.
2. Alternatively, DNS responses switch from public IPs to internal IPs, exploiting the gap between validation time and connection time.
3. This can expand to internal port scanning, configuration changes, and internal API operations.

4. Attacker Position and Execution Location

• External attackers who can reach the MLflow Web UI/API from the internet.
• Connecting to metadata and internal services in the same cloud or network, using the MLflow server as a stepping stone.

5. Visibility for Victims and Administrators

Victims and Users

• No user action is required. Public MLflow servers are directly targeted.

Administrators and SOCs

• Suspicious webhook creation and testing, redirects from external URLs to internal or link-local IPs, and metadata API responses serve as clues.
• After a compromise, API calls using the MLflow server's cloud role may be visible.

6. Success and Failure Conditions

Success Conditions

• Vulnerable MLflow 3.14.0 or earlier.
• Webhook API on the Tracking Server is reachable without authentication.
• Network communication is possible from the MLflow host to internal services/metadata.
• The cloud role has valid permissions, increasing the impact after credential theft.

Failure Conditions

• Updating to MLflow 3.15.0 or later.
• Making MLflow private from the internet and protecting it with an authenticated reverse proxy or similar methods.
• Metadata service protections, least-privilege roles, and egress controls.
• Validating webhook destination IPs after connection and at each redirect.

7. What Happens Upon Success

• Reading cloud metadata and temporary IAM credentials.
• Retrieving internal service information, port scanning, and blind writes.
• Accessing cloud assets within the privilege scope of the stolen credentials.

8. Observable Logs

Email

• Email is not an attack vector.

Proxy / SWG / DNS

• Connections to 169.254.169.254 or RFC1918 addresses immediately following a connection from MLflow to the attacker's public host.
• DNS responses for the same hostname change from public IPs to internal IPs in a short time.

Endpoint / EDR

• HTTP connections from the MLflow process to internal networks/metadata. Network telemetry is important because this usually happens without additional processes.

Identity / IdP

• API usage from new IPs and User-Agents using stolen temporary cloud credentials.

SaaS / Cloud

• Abnormal enumeration of MLflow roles, retrieval of secrets, or resource operations in CloudTrail, etc.
• IMDS access logs or host network flows.

Network

• HTTP connections from the MLflow server to link-local, loopback, RFC1918, and internal management ports.

9. Attack Success Determination

• Attack Attempt Observed (Success Unconfirmed): Only suspicious requests or vulnerability scans against the webhook API. Internal connections and response retrievals are not confirmed.
• Initial Execution Confirmed: Webhooks are created and tested, and the MLflow server connects to the specified URL.
• Information Theft or Session Compromise Confirmed: Metadata/IAM credential responses are returned, or cloud API usage with stolen credentials is confirmed.
• Post-Compromise Activity Confirmed: Secret retrieval, lateral movement, or resource modifications using the stolen role are confirmed.

"Attack Attempt Observed (Success Unconfirmed)" means suspicious requests or payloads are identified, but code execution or information theft is not established. Escalate the severity based on subsequent evidence.

10. Investigation Playbook

Trigger

• Anonymous access to the MLflow Webhook API.
• Connections from the MLflow host to 169.254.169.254 or internal management APIs.
• MLflow cloud roles used from unknown IPs.

Initial Check

• Check the version, public exposure scope, webhook list, creator, creation time, and test history.
• Recover the URL, redirect chain, DNS responses, and final connection IP.

Endpoint

• Preserve MLflow process connection history, application logs, and reverse proxy logs.
• Do not rule out SSRF just because there are no file creations or child processes.

Authentication and Cloud

• Investigate role sessions, CloudTrail, secret access, and permission changes starting from the webhook timestamp.
• Revoke/rotate the compromised role credentials and apply least privilege.

Subsequent Operations

• Search for operations across all regions using the same IP, User-Agent, and Access Key ID.

Containment

• Make MLflow private or restrict access, and update to version 3.15.0 or later.
• Disable/delete webhooks, and rotate role credentials and any exposed secrets.

Determination Categories

• Attack attempt only
• Outbound SSRF connection confirmed
• Internal response retrieval confirmed
• Credential theft confirmed
• Subsequent cloud compromise confirmed

11. Defense and Detection Ideas

Single Event

• Anonymous webhook creation/testing.
• HTTP connections from the MLflow process to 169.254.169.254, localhost, or RFC1918.

Time-Series Correlation

• Webhook creation -> Public host -> Internal IP redirect -> IMDS response -> External API usage by the same role.

Threat Hunting Perspective

• Re-resolve and classify webhook URLs and redirect destinations from the past 30 days.
• Deviations in source IPs, User-Agents, and regions for MLflow role usage.

Log Gaps

• Webhook bodies/responses, redirect tracking, DNS responses, process-level network traffic, and IMDS access.

Priority Actions

• Update to version 3.15.0 or later.
• Make the Tracking Server private and add authentication.
• Implement cloud role least privilege and IMDS protection.
• Deny egress to link-local and internal management networks.

12. Facts / Inference / Hypothesis

Facts

• CVE-2026-64849 affects MLflow 3.14.0 and earlier, and is fixed in 3.15.0.
• The webhook API is available without authentication in default configurations.
• After validating the original URL, redirect destinations and actual connection IPs are not fully re-validated.
• Reading internal response bodies via 302 and performing blind writes while maintaining POST via 307/308 are possible.
• CISA added it to the KEV list due to active exploitation.

Inference

• Publicly exposed MLflow instances combined with powerful cloud roles are top priority investigation targets.
• EDR process generation alone is easy to miss; correlation of application, API, network, and cloud audit logs is required.

Hypothesis

• After checking IMDS, attackers may prioritize exploring Secrets Manager, object storage, and ML assets based on the obtained role permissions.

13. MITRE ATT&CK Mapping

• T1190 – Exploit Public-Facing Application (High Confidence)
• T1552.005 – Unsecured Credentials: Cloud Instance Metadata API (High Confidence)
• T1046 – Network Service Discovery (Medium Confidence): Internal port scanning capability exists, but execution in individual active exploitation cases is unconfirmed.
• T1078.004 – Valid Accounts: Cloud Accounts (Medium Confidence): If stolen temporary credentials are used subsequently.

14. Unknowns and Additional Investigation

• Active exploitation actors, number of targets, and scope of compromise.
• Cloud permissions obtained and subsequent operations in each incident.
• Published complete IOCs.

15. Impact on SOCs and General Enterprises

Exposing ML platforms externally for testing purposes while assigning high-privilege cloud roles can happen in any organization. Asset inventories must simultaneously verify not only the presence of MLflow but also its exposure scope, authentication, role permissions, and IMDS reachability.

16. Summary by Target Audience

For SOCs

Correlate webhook APIs, internal connections, and cloud role usage in a timeline.

For Administrators

Update MLflow to version 3.15.0 or later, make it private, enforce authentication, and apply the principle of least privilege.

For Users

No end-user action is required; response is needed from MLflow administrators.