Hackers Are Exploiting an MLflow Bug to Steal Cloud Credentials Within Hours of Disclosure

[VoidKnight]

CISA has added a critical MLflow vulnerability to its Known Exploited Vulnerabilities catalog and given federal agencies until September 2 to patch it, after security firm watchTowr detected active exploitation attempts hitting its honeypot network within hours of the flaw even being assigned a CVE number. MLflow is a widely used open source platform, backed by the Linux Foundation, for managing machine learning models, and it reportedly gets more than 60 million monthly downloads.

The vulnerability itself, tracked as CVE-2026-64849 with a CVSS score of 9.3, is a server side request forgery issue in MLflow's webhook testing feature. On a default MLflow Tracking Server, anyone who can reach the service can create a webhook and trigger a test without ever logging in, and that test can be abused to make the server issue HTTP requests to internal only systems it would never normally be allowed to reach on the attacker's behalf, including cloud metadata endpoints that hold temporary but genuinely powerful identity credentials.

What makes this particularly dangerous is exactly the kind of access those metadata endpoints can leak. Successful exploitation can hand an attacker AWS Identity and Access Management credentials, service account tokens, environment variables, and other secrets sitting on whatever internal cloud infrastructure the exposed MLflow server happens to be running inside of, essentially turning a machine learning experiment tracking tool into a launchpad for a much broader cloud account compromise.

The flaw affects every MLflow version before 3.15.0, and while MLflow did add some outbound destination validation back in version 3.10.0 specifically to stop webhooks from reaching private or reserved IP addresses, that protection apparently only applied to the initial hostname a request was aimed at, leaving a gap attackers could still route around. watchTowr's honeypot data shows attackers indiscriminately scanning for exposed MLflow deployments almost immediately after the CVE was publicly assigned, rather than carefully targeting specific known organizations.

Because MLflow is so often treated as just a convenient local tool for experimenting with AI models rather than genuine production infrastructure, plenty of teams likely have an exposed instance running somewhere they have never actually thought to secure

Attackers Exploit MLflow SSRF Flaw to Steal Cloud Credentials and Secretsthehackernews.com

[Ronaldo]

MLflow being treated as just a local experimentation tool by so many teams rather than genuine production infrastructure is exactly the mismatch that keeps producing these exact kinds of severe vulnerabilities across the AI tooling ecosystem lately. Nobody applies the same security rigor to something they think of as a developer's personal sandbox.

[Megan95]

Would genuinely love to see actual data on how many exposed MLflow instances are still sitting out there completely unpatched right now, months after this exact flaw was first disclosed and despite the CISA deadline pressure. My honest guess is the real number is a lot higher than anyone currently reporting on this story would like to admit

[Brandon18]

Turning a machine learning experiment tracker into a full cloud credential theft launchpad is such a clean example of how deeply AI development tooling now sits inside genuinely sensitive cloud infrastructure. A tool built for tracking model metrics was never originally designed with this level of security exposure in mind at all

[Ivory Boar]

Scanning within hours of CVE assignment rather than carefully targeting specific known organizations tells you attackers are running broad, automated sweeps across the entire internet rather than pursuing anything targeted here.
That is honestly worse news for smaller organizations who might otherwise assume they are simply too unimportant to be worth attacking specifically