Hours. That is how long it took between this CVE being assigned and mass scanning starting.
CVE-2026-64849 — CVSS 9.3 — unauthenticated SSRF in MLflow, the tracking server sitting at the centre of most enterprise ML pipelines. Assigned August 17. Exploited the same day. In CISA's KEV catalog days later.
WHAT ACTUALLY HAPPENED
MLflow's default Tracking Server exposes the model-registry webhooks API with no authentication at all. That API can be made to issue HTTP requests on the server's behalf.
Attackers point it at the cloud metadata service — the internal endpoint every VM in AWS, Azure and GCP uses to fetch its own instance credentials — and read the response back out.
The result is not a crashed service. It is a valid set of cloud provider credentials, belonging to the role attached to your ML infrastructure.
All versions before 3.15.0 are affected. Financially motivated actors and initial access brokers are scanning indiscriminately for exposed instances.
WHY AI INFRASTRUCTURE IS THE NEW EDGE
Nobody put MLflow behind the same controls as a production API. It was stood up by a data science team, it holds experiments and models, and it feels internal.
But it runs in your cloud account, with an instance role, and increasingly it is reachable from the internet because someone needed to share a dashboard.
That makes it edge infrastructure with none of the edge hardening. No authentication, no WAF, no one paging on it.
And the payoff is asymmetric: the attacker does not want your model weights, they want the credentials the machine hosting them carries. One SSRF becomes lateral movement into the cloud account itself.
Every AI platform you deploy inherits the blast radius of the identity you attach to it.
WHAT TO DO NOW
UPGRADE TO MLFLOW 3.15.0 — anything earlier exposes the webhooks API unauthenticated by default.
ENFORCE IMDSv2 — session-token-required metadata makes the classic SSRF-to-credential-theft path fail even when the SSRF works.
GET ML TOOLING OFF THE PUBLIC INTERNET — tracking servers, notebook hosts and model registries belong behind SSO and a private network, not a public IP.
ROTATE AND SCOPE THE INSTANCE ROLE — assume the credentials leaked, rotate them, then cut that role down to what the workload genuinely needs.
Your AI stack is production infrastructure. Attackers already treat it that way — the question is whether your security programme does.
Who owns patching for the ML platforms in your cloud account: the data team, or security?