CVE-2026-64849 is an unauthenticated server-side request forgery flaw in MLflow, the open-source platform for tracking machine-learning experiments and registering models. It carries a CVSS 9.3 and is fixed in MLflow 3.15.0.

watchTowr reported exploitation attempts against internet-facing instances within hours of the CVE being assigned on 17 August 2026.

The endpoint

A default MLflow Tracking Server exposes POST /api/2.0/mlflow/webhooks//test without authentication. It exists so you can check that a model-registry webhook is wired up correctly: MLflow calls the URL and hands you back the status and body it got.

That last part is what turns an SSRF into a full-read one. Many SSRFs are blind — you can make the server issue a request but cannot see the answer. This one returns the response.

The bug is not a missing check

MLflow does validate the webhook URL. There is a function for it. The problem is what happens after.

Per the GitHub advisory, the validated address is never pinned. MLflow checks the destination, then makes the request following HTTP redirects, and re-resolves the hostname when it does. So a name that passed validation can answer differently a moment later — either because the first server replies with a redirect to somewhere internal, or because the DNS record itself now returns an internal address. That second variant is DNS rebinding, and it has been a known SSRF bypass for years.

This is a time-of-check-to-time-of-use bug wearing network clothing. The check was true when it ran. Nothing kept it true.

It also bypassed an earlier mitigation, which is the detail worth keeping: this is at least the second attempt at closing this hole in this component — the same shape as N-able's incomplete patch and ShieldBreak going round Microsoft's Defender fix.

What attackers are going for

Cloud metadata.

Every major cloud runs a metadata service on a fixed internal address that any process on the instance can query, and on many configurations it will hand out the instance's role credentials to anyone who asks. An unauthenticated full-read SSRF on a cloud-hosted box is a direct line to it, which is why watchTowr describes the observed activity as extraction of credentials and secrets rather than reconnaissance.

Note what that means for blast radius. The prize is not your experiment tracking data. It is whatever the instance's IAM role can do, which on an ML platform is frequently a large S3 bucket of training data and a model registry.

Why MLflow specifically

Because of who installs it and how.

MLflow is developer infrastructure that data teams stand up themselves, often outside whatever process governs production services — no authentication in front of it, because it is "internal", on a cloud host, because that is where the GPUs are. The result is a class of software with the exposure profile of a production service and the operational care of a notebook. We made the same point about Langflow's unauthenticated RCE and the Odysseus AI workspace at CVSS 9.9.

The hours between CVE assignment and mass scanning is the other half of it. There is no useful window in which to schedule a maintenance slot.

What to do

  • Upgrade to 3.15.0 or later. Nothing else fixes it.
  • Take MLflow off the public internet. It ships with no authentication and was never designed to face the world.
  • Assume the instance role is compromised if you were exposed. Rotate its credentials and read its CloudTrail or equivalent for the exposure window — do not wait for confirmation you were hit.
  • Require IMDSv2, or the equivalent hop-limited metadata policy on your cloud. It does not fix the SSRF and it does defeat the most valuable thing to do with one.
  • Search access logs for requests to the webhook test path. It is a specific URL with a legitimate but rare use, so hits are worth reading individually.

What is not established

  • How many instances were compromised. watchTowr reports honeypot telemetry and scanning, not a count of successful intrusions.
  • Who is scanning. No actor has been named, and indiscriminate scanning after a CVE rarely maps to one.
  • What has been taken. Credential theft is the observed objective; no victim has disclosed an outcome.