MLflow SSRF Flaw (CVE-2026-64849) Added to CISA KEV Amid Active Exploitation

CISA has added CVE-2026-64849, a server-side request forgery (SSRF) vulnerability in MLflow, to its Known Exploited Vulnerabilities (KEV) catalog, indicating the flaw is being actively exploited in the wild.

What Happened

According to the CISA KEV entry, MLflow contains an SSRF vulnerability that allows an attacker to induce the server to make requests on their behalf. Critically, the flaw returns both response_status and response_body to the attacker, meaning it isn't a blind SSRF — responses from internal endpoints can be read back directly. This makes reaching internal services or cloud instance metadata endpoints (e.g., IMDS on AWS/Azure/GCP) particularly dangerous, as credentials or configuration data returned by those services could be exfiltrated.

Why It Matters for Defenders

MLflow is widely deployed as an ML experiment-tracking and model-registry server, often running with elevated cloud IAM permissions to manage artifacts and models in object storage. An SSRF that can reach cloud metadata services is a well-worn path to credential theft and lateral movement into broader cloud environments — not just an issue confined to the MLflow application itself. CISA's KEV listing confirms this is not theoretical: exploitation has already been observed. No CVSS score has been published yet, and no ransomware association has been confirmed at this time.

What Defenders Should Do Now

• Identify any internet-facing or internally-exposed MLflow servers in your environment and inventory their versions.
• Apply vendor guidance/patches from MLflow as soon as they are available; track the linked pull request for the underlying fix.
• Restrict outbound network access from MLflow hosts — block or tightly filter requests to cloud metadata IPs (e.g., 169.254.169.254) at the host or network layer as a compensating control.
• Hunt for anomalous outbound HTTP requests originating from MLflow server processes, especially to internal IP ranges, localhost, or metadata service addresses.
• Review MLflow application and proxy/access logs for parameters or API calls that accept attacker-controlled URLs, and look for unexpected response patterns tied to those requests.
• Enforce least-privilege IAM roles on hosts running MLflow so a successful SSRF-to-metadata chain yields minimal usable credentials.

Developing Intel

This is a fresh, same-day KEV addition and details are still emerging — CVSS scoring, affected version ranges, and full patch guidance were not yet available at time of writing. Detection content for this technique will follow as more information is confirmed. Track the underlying fix and technical details at the source: https://github.com/mlflow/mlflow/pull/24258.