Press play to start listening
The US Cybersecurity and Infrastructure Security Agency (CISA) has added a critical MLflow security vulnerability to its Known Exploited Vulnerabilities catalog after citing “evidence of active exploitation” in the wild.
The vulnerability is assigned CVE-2026-64849 and given a CVSS score of 9.3. It was added to the KEV list on August 19. CISA has given federal civilian agencies until September 2, 2026, to fix it under Binding Operational Directive (BOD) 26-04. While this directive applies to federal civilian agencies, CISA also advises other organizations to prioritize vulnerabilities listed in its KEV catalog.
For your information, MLflow is an open-source AI engineering platform backed by the Linux Foundation and used by thousands of organizations to build, test, monitor, and improve AI applications. MLflow project claims that MLflow attracts more than 30 million monthly downloads.
How the MLflow flaw works
CVE-2026-64849 is an unauthenticated server-side request forgery (SSRF) flaw in MLflow’s webhook system. In simple terms, it can trick an MLflow server into sending requests to places that should normally be hidden from the internet, such as internal services or cloud systems.
The problem is made worse because the webhook API doesn’t require users to log in on a default MLflow Tracking Server. This includes the /api/2.0/mlflow/webhooks/{id}/test endpoint, which can return the response from the server it was asked to contact.
The problem emerges from an earlier SSRF protection mechanism where MLflow checks the original webhook URL and blocks non-public IP addresses, but the server didn’t re-check the destination after following an HTTP redirect. An attacker can therefore point a webhook to an external server they control and have it redirect MLflow to an internal address, including cloud metadata services.
And, since the webhook test endpoint returns the upstream response status and body, the vulnerability can allow attackers to read information from internal services. The advisory also notes that 307 and 308 redirects can preserve the original POST request. This could allow attackers to send requests to certain internal services.
Attackers Are Already Scanning for Exposed Servers
The vulnerability was first reported privately by researcher @freeman-bb on June 12th, followed by independent discovery by @AUTHENSOR on June 26. The flaw affects MLflow versions before 3.15.0. MLflow fixed the issue in version 3.15.0 by adding connection-time SSRF protection that validates the IP address of the server actually reached.
However, the vulnerability quickly drew attention from attackers, reports security research group watchTowr, which observed indiscriminate scanning for exposed MLflow instances within hours of the CVE being assigned on August 17. Moreover, its telemetry also showed attempts to use vulnerable MLflow servers to reach internal services and cloud metadata endpoints to access/exfiltrate credentials and secrets.
It is essential that organizations running exposed MLflow servers upgrade to version 3.15.0 or later as soon as possible to stay safe. Other security best practices in this situation include reviewing logs for suspicious webhook activity and investigating whether sensitive credentials may have been accessible through the vulnerable server.
Expert’s Commentary
Robbie Mueller, solutions engineer at ArmorCode, told Hackread.com that the vulnerability is particularly concerning because it can be exploited remotely without authentication.
“The impact depends heavily on permissions associated with a compromised MLflow workload. If an attacker obtains credentials to an overly privileged cloud identity, that exploitation of MLflow can turn into a much larger incident as the attack pivots,” Mueller said.
He also warned about the potential consequences of accessing cloud credentials through a vulnerable MLflow server.
“One possible worst-case scenario is an MLflow instance gets exploited, and the attacker uses that to retrieve cloud credentials/secrets, and starts enumerating the cloud environment to access additional resources. Depending on the permissions attached to that identity, that could lead to the compromise of sensitive data, secrets, storage, additional workloads, and cloud management APIs.”
