A DNS-rebinding trick against the server every ML team stands up first
MLflow is the piece of AI infrastructure that gets deployed before anyone thinks hard about its exposure. Teams stand up a Tracking Server to log experiments, register models, and route webhook notifications, usually on a shared internal network, sometimes with a public load balancer in front of it because a data scientist needed to check a dashboard from home. It is the kind of tool that platform teams inherit rather than provision deliberately, which is exactly why its default network posture rarely gets the same scrutiny as a production database or an API gateway. CVE-2026-64849 targets that server directly, and it does so through a DNS-rebinding bypass of the server-side request forgery protections MLflow's own security team had already built into the webhook delivery feature.
MLflow's maintainers described the mechanic plainly: an unauthenticated attacker who can reach the tracking server can make it issue HTTP requests to arbitrary internal, loopback, or cloud metadata endpoints, then read the responses through the built-in test endpoint. There is no credential requirement and no privileged access needed on the attacker's side. The only precondition is network reachability, which is precisely the condition most MLflow deployments satisfy by default, since the whole point of a shared tracking server is to be reachable by every data scientist on the team without friction. That same convenience is what makes the attack trivial to carry out once an adversary has any foothold on the internal network, or in cases where the server sits behind a permissive load balancer, from the open internet.
Why the target is credentials, not just model data
SSRF bugs against cloud-hosted infrastructure have a predictable payoff: the cloud metadata service. On AWS, GCP, and Azure alike, a workload's own metadata endpoint hands back short-lived credentials scoped to whatever IAM role or service account the instance runs under. A tracking server tricked into fetching that endpoint on an attacker's behalf effectively hands over the keys to everything that role can touch, which in a typical ML pipeline includes S3 buckets full of training data, model artifact stores, and often the CI/CD credentials used to push updates.
That is a materially different risk than losing experiment logs. An attacker with a stolen IAM credential can pivot laterally into whatever else that role reaches, and MLflow's tracking servers frequently run with broader permissions than they need because nobody scoped them tightly in the first place. CISA's own framing, that this class of bug is a frequent attack vector precisely because it is quiet and hard to detect from the outside, matches the pattern here.
The CISA clock and what it actually forces
CISA's August 19 addition to the Known Exploited Vulnerabilities catalog is not a courtesy notice. Binding Operational Directive 26-04 gives federal civilian agencies a two-week window to patch systems on the list, and CISA's public language, calling this an attack vector that poses significant risk to the federal enterprise, signals active exploitation rather than theoretical concern. For a private-sector CTO, the KEV listing is the fastest available signal that a bug has moved from research finding to something threat actors are actually using.
The fix is a version bump to MLflow 3.15.0, which is a small operational lift compared to most infrastructure patches. The harder part is inventory: knowing every tracking server your ML teams stood up, including the ones that predate your current platform team and were never registered anywhere formal. Shadow MLflow instances are common precisely because the tool is so easy to spin up, and that ease of adoption is now the same property making this bug hard to fully remediate.
Checking whether you were already exposed
Because the bug requires no authentication and leaves few obvious traces, a patch-and-move-on response is not sufficient. Security teams should pull tracking server access logs looking for requests to the webhook test endpoint originating from outside expected admin ranges, and treat any hit as a presumed credential compromise until proven otherwise. That means rotating the IAM role or service account tied to the affected instance, not just restarting the application.
Cloud providers make this easier than it used to be. AWS, GCP, and Azure all support scoping instance credentials down to the minimum required permissions, and CloudTrail, Cloud Audit Logs, or Azure Activity Log entries showing metadata service calls from the tracking server's own role are a useful cross-check for anomalous activity in the window before the patch went in. Teams that cannot produce these logs at all have a bigger gap than this one CVE, and it is worth treating that logging gap as its own finding.
The decision this puts on your desk
If your organization runs MLflow anywhere, patching to 3.15.0 is the non-negotiable first step, but it does not close the underlying gap. Every tracking server should sit behind authentication and network segmentation regardless of patch level, because history says another SSRF variant will surface in this same webhook feature eventually. Treat any MLflow instance reachable from a broad internal network, let alone the public internet, as a finding worth escalating this week, and budget for a follow-up hardening pass once the immediate patch lands.
The governance question underneath this incident is broader than one product. AI tooling adoption inside engineering organizations has consistently outpaced the security review process that normally gates new infrastructure, and MLflow's rapid, grassroots deployment pattern is typical of how most open-source AI platforms enter production today. CTOs should ask their platform and security teams for a current inventory of every AI/ML tool with a network-facing server component. Expect this to be the first of several similar findings, since the same fast-adoption dynamic applies to vector databases, agent frameworks, and inference gateways that entered production the same informal way MLflow did.
