Latest / The Digital Warfare Podcast / EP. 147: CVE-2026-64849 Turns MLflow Into a Cloud Credential Theft Path
Transcript
- Digital Warfare: You're listening to the Digital Warfare Podcast. Today, we are covering a critical ML Flow vulnerability that can turn an exposed machine learning platform into a pathway toward cloud credentials and internal services. And the key issue is not simply server-side request forgery, it is what the ML Flow server can reach on your behalf. Here's what happened: the vulnerability is tracked as CVE-2026-64849. It carries a CVSS score of 9.3 and affects ML Flow versions before 3.15.0. The floor exists in ML Flow's webhook delivery process. MLflow introduced protections designed to prevent webhook requests from reaching private IP addresses, loopback interfaces, and cloud metadata services. But the protection validated only the original destination. It did not properly validate where that request could be redirected afterward. An attacker can therefore provide a public HTTPS address that passes the initial security check. That server then responds with an HTTP redirect toward an internal destination. ML flow follows the redirect. The new destination is not revalidated, and because the vulnerable webhook test endpoint returns the upstream response body, the attacker can potentially read information retrieved from the internal service. That changes the impact dramatically. This is not blind SSRF, it is full red SSRF. And on a cloud-hosted ML Flow server, one of the most valuable targets is the instance metadata service. Cloud metadata endpoints can expose temporary IAM credentials, role information, tokens, and configuration data associated with the workload. If those credentials carry meaningful permissions, the attack can move from one exposed ML flow server into cloud storage, databases. Secrets platforms or other infrastructure. The attack requires no ML Flow account on a default deployment, no user interaction is required, and attack complexity is considered low. The same weakness can also be used to probe internal services that are unreachable directly from the internet. That means an exposed ML Flow instance may effectively become an internal network proxy controlled by an external attacker. ML Flow addressed the issue by adding connection time SSRF protection. That validates the actual peer IP after each connection is established, including redirected connections. Organizations should upgrade to ML Flow 3.15.0 or later, but patching is only the first step. Security teams should identify every ML flow tracking server, especially systems created for temporary experiments, research project, development environments, or data science testing. Those systems frequently escape normal asset management processes. Next, Determine whether they were internet accessible. Review logs for suspicious webhook creation and test activity. Look for outbound requests toward metadata addresses such as one six nine.254.169.254, loopback systems, or unexpected private network ranges. If there is any evidence of exploitation, rotate the cloud credentials available to the affected workload. Review IAM activity. Investigate access to secrets, storage, Databases and other services reachable using those identities, and place ML flow behind strong authentication and network controls rather than relying on default exposure. The strategic lesson is direct. AI infrastructure is becoming enterprise infrastructure. Data science platforms may begin as experiments, but they often inherit real cloud identities and real network access. Attackers understand that the vulnerable AI tool may not contain the prize. It may simply contain the credentials that lead to it. This has been your Digital Warfare Daily Brief. Stay secure. We'll see you tomorrow.