WASHINGTON, 22 AUG 2026 — A server-side request forgery flaw in MLflow, the experiment-tracking platform used by machine learning teams, is being exploited to steal cloud credentials. CVE-2026-64849 scores 9.3, requires no authentication, and affects every version before 3.15.0.
It was disclosed on 17 August. CISA added it to the Known Exploited Vulnerabilities catalogue on 19 August, two days later. Honeypots have captured payloads aimed at the cloud metadata endpoints of AWS, Google Cloud and Azure.
What the flaw does
In a server-side request forgery, an outside attacker forces an exposed server to issue HTTP requests on their behalf. The flaw effectively turns the service into an internal proxy, letting the attacker reach anything the server can.
In confirmed incidents attackers exfiltrated cloud credentials, then used them to enumerate cloud resources, deploy cryptocurrency miners, and establish persistence by creating new identity and access management users and roles.
The metadata endpoint is the target, and it has been for years
Every major cloud provider runs an instance metadata service reachable from inside a virtual machine at a fixed link-local address. It exists so that workloads can discover their own configuration and, critically, obtain temporary credentials for the role the instance was assigned.
That design assumes anything making requests from inside the instance is authorised to act as the instance. Server-side request forgery breaks this assumption. The metadata endpoint became the standard second step for this kind of attack chain after the Capital One breach in 2019 made the pattern famous.
The attacker obtains temporary credentials for the workload's role, not a permanent password. The severity of the breach therefore depends entirely on that role's permissions — the difference between a contained incident and a catastrophe.
While the flaw is in MLflow, the blast radius is set by an IAM policy somebody wrote months earlier. Machine learning workloads are routinely granted broad object storage access because that is where the training data is, and broad object storage access is exactly what an attacker wants.
Why this platform specifically
MLflow is not obscure. It is one of the standard tools for tracking experiments, parameters and model artefacts, and it is deployed widely enough that an internet-wide scan finds plenty of instances.
The structural problem is who deploys it. Experiment trackers are stood up by data science teams to solve a data science problem. They are frequently not in the asset inventory the security team maintains, not behind the single sign-on the rest of the estate uses, and not in the patch cycle, because nobody classified them as infrastructure. They look like a research tool.
They are, in fact, a web application running inside a cloud account with a credential-bearing role attached. This mismatch — between a tool's perception as a research utility and its reality as a privileged web application — is common across the MLOps stack. It is why this class of vulnerability will recur long after this specific CVE is patched.
The uncomfortable comparison is to web application frameworks in the early 2010s. The machine learning toolchain today has a similar security posture, prioritising rapid feature development over basics like mandatory authentication, and is often deployed by people whose main job is not operations.
Two days from disclosure to the exploited catalogue
The two-day interval is the key lesson here.
A CISA listing means exploitation has been observed, not merely predicted. Reaching that state within two days of public disclosure means either that attackers were already scanning for the pattern, or that the disclosure itself supplied enough detail for weaponisation almost immediately. For an unauthenticated SSRF with a public patch to diff, the second is unremarkable.
A patch schedule measured in weeks is irrelevant here. The window for this flaw closed before most organisations had finished reading the advisory. The defensive question becomes what an attacker could have reached, not whether you patched in time.
What actually reduces the damage
Patching to 3.15.0 is the instruction, and three things matter more than the patch because they bound the outcome regardless of the next flaw.
The first is exposure. An experiment tracker has no business being reachable from the public internet. Most instances are exposed because it was convenient during setup and nobody revisited it, not because remote access was a requirement.
The second is the instance role. The temporary credentials an attacker obtains carry exactly the permissions the workload was granted. A role scoped to the specific buckets a training job reads produces a contained incident; a role with broad storage or IAM permissions produces the one described in the advisories, where attackers created their own users.
The third is metadata service configuration. AWS instances can require session-oriented requests for metadata access, which defeats the simplest SSRF chains outright. It is a configuration change rather than a project, and organisations that made it are substantially less exposed to every future flaw of this shape.
Why regional teams should treat this as an inventory problem
Across ASEAN the machine learning tooling picture is the same as everywhere else: adopted quickly, by teams hired for modelling rather than operations, at organisations whose security functions are stretched.
The real takeaway is not about this specific patch. It is about answering a question most organisations cannot: what internal services have non-operations teams deployed, what cloud roles do they carry, and which are internet-reachable? Experiment trackers, notebook servers, vector databases, model registries and annotation tools all fit the pattern.
An organisation that can produce that list has a manageable problem. One that cannot will learn its contents from an advisory.
What remains unconfirmed
CISA has not disclosed the victims, the attackers, or the outcomes of the intrusions. The number of affected organisations is not published, and no attribution has been offered.
It is not established when exploitation began relative to the 17 August disclosure, how many internet-exposed instances remain unpatched, whether any specific sector is being targeted, or whether the cryptomining and persistence activity described comes from one actor or several. No indicators of compromise appear in the material reviewed.
What to watch for
Watch whether this attack pattern spreads to adjacent tools. The logic that makes MLflow a target also applies to model registries, feature stores, and notebook servers. Attackers who built scanning infrastructure for one will reuse it for the others.
The second is whether cloud providers move on metadata defaults. Requiring session-oriented metadata requests by default rather than as an opt-in would retire this entire attack chain, and the argument for doing so gets stronger with each SSRF of this kind.
The third is IAM hygiene reporting. If post-incident accounts describe attackers creating new users and roles, the permissions that allowed it are the finding, not the SSRF.
View author profile → · Editorial policy
