CISA Adds MLflow CVE-2026-64849 to KEV Catalog

CISA added CVE-2026-64849, a critical unauthenticated SSRF vulnerability in MLflow, to its Known Exploited Vulnerabilities catalog on August 19, 2026. The CISA warning and exploitation details make the operational priority clear for teams running MLflow Tracking Servers: upgrade to MLflow 3.15.0 or later and investigate exposed deployments.

The flaw carries a CVSS score of 9.3 and affects every MLflow version before 3.15.0. Attackers can abuse the model-registry webhooks API without authentication to make the server send requests into internal networks and return the response body to the attacker.

A DNS-Rebinding SSRF With Full Response Readback

The vulnerable endpoint is POST /api/2.0/mlflow/webhooks/{id}/test. MLflow validates the webhook URL with _validate_webhook_url() in mlflow/utils/validation.py, using socket.getaddrinfo() to check whether the hostname resolves to a public IP address.

Validation ends before the request is made. MLflow discards the resolved address, then sends the webhook request through session.post(webhook.url) without disabling redirects or pinning the connection to the validated IP. The gap enables two exploitation paths.

An attacker can provide a public URL that passes validation and return an HTTP 302 redirect to an internal destination such as http://169.254.169.254/. MLflow follows the redirect without performing a second address check. DNS rebinding provides another route, returning a public address during validation and a private address when the HTTP client connects.

The endpoint returns both response_status and response_body. Internal services therefore become readable through the vulnerable server, rather than merely reachable for blind port scanning.

Cloud Metadata Is the Immediate Target

Active exploitation has focused on cloud instance metadata services, including AWS IMDS, Azure IMDS, and GCP metadata endpoints. Responses can contain temporary IAM credentials, API secrets, and access tokens. The same primitive supports internal host and port discovery behind a network perimeter.

watchTowr’s Attacker Eye honeypot network detected indiscriminate scanning and exploitation against cloud-hosted MLflow systems within hours of the CVE assignment on August 17. MLflow’s scale increases the potential exposure: the platform has more than 30 million monthly downloads and over 27,000 GitHub stars, with deployments supporting machine learning lifecycle operations, LLM engineering, and agent tracking.

For teams responsible for AI application observability, this incident highlights a boundary that metrics and traces do not protect by themselves. A tracking server can hold access to cloud credentials even when the models and application APIs are separately secured.

Versions and Response Timeline

Item	Detail
Vulnerability	CVE-2026-64849, GHSA-7gwp-5pfp-969j
Severity	CVSS 9.3, Critical
Affected releases	MLflow versions before 3.15.0
Patched release	MLflow 3.15.0, via Pull Request #24258
CISA action	Added to KEV on August 19, 2026
Federal requirement	FCEB agencies must remediate exposed instances under BOD 26-04

The vulnerability was privately reported on June 12 and independently submitted through GitHub Issue #24179 on June 26. Public disclosure and the 3.15.0 patch followed on August 17. CISA’s KEV listing moved the issue from routine patch management into an active-exploitation response.

Required Actions for MLflow Operators

Upgrade every MLflow installation to 3.15.0 or later, including instances deployed from immutable images or automated infrastructure templates. Identify internet-facing Tracking Servers and place them behind a VPN, an OAuth or OIDC-enabled reverse proxy, or MLflow’s authentication plugin. Guidance on securing AI agents is relevant here because the same identity and network controls protect the surrounding automation layer.

Rotate AWS, Azure, and GCP credentials available to affected hosts. Review CloudTrail and equivalent cloud audit logs for unusual metadata access, token use, API calls, and activity originating from MLflow server addresses. Treat any exposed unauthenticated instance as potentially compromised until its credentials and network paths have been reviewed, then add SSRF checks and private-address egress controls at the infrastructure layer.