CVE-2026-64849 carries a CVSS score of 9.3, and the exploitation pattern behind it is more useful to understand than the number itself: it’s a server-side request forgery flaw in MLflow, the open-source machine learning tracking platform, that lets an unauthenticated attacker turn an exposed MLflow server into a proxy for reaching internal cloud infrastructure it was never supposed to touch. Security researchers at watchTowr reported indiscriminate scanning for vulnerable instances within hours of the CVE being assigned on August 17, and it was still ongoing a day later.
The reason this matters beyond the ML-ops world it originates in: any business running self-hosted tools on cloud infrastructure, MLflow or otherwise, is one misconfigured internal service away from the same category of exposure, and the mechanism behind this specific flaw is a genuinely useful case study in why.
How the Exploit Works
MLflow’s model-registry feature includes webhooks, a legitimate mechanism for the platform to make outbound HTTP requests when certain events happen (a new model version registered, a run completed). According to watchTowr’s analysis, attackers found a way to manipulate how MLflow handles web redirects within that webhook system, bypassing an earlier security fix and using the platform’s own legitimate outbound-request capability to reach internal cloud metadata endpoints instead of its intended external targets.
Cloud metadata endpoints (the internal service every major cloud provider exposes to instances for retrieving configuration data, and in many misconfigured setups, temporary security credentials) are exactly the kind of internal-only resource that’s supposed to be unreachable from the public internet. SSRF vulnerabilities exist specifically because an application making outbound requests on a server’s behalf can sometimes be tricked into requesting something the attacker chose, not something the application intended, and a server sitting on cloud infrastructure with network access to its own metadata endpoint is the highest-value target that pattern can reach.
What’s Being Stolen
watchTowr’s principal threat intelligence specialist described the goal plainly: exfiltrating “credentials and secrets from well-known internal IP addresses and services.” In practice, for a cloud-hosted MLflow instance, that means the temporary access credentials a cloud provider issues to the instance itself, credentials that, depending on how permissively the instance’s IAM role was configured, can grant access to considerably more than MLflow was ever meant to touch: storage buckets, other internal services, sometimes broader account-level resources if the role wasn’t scoped tightly.
This is the part that turns a single-application vulnerability into a full infrastructure compromise. The attacker doesn’t need to find a flaw in every service running on a network; compromising one internet-facing application with an overly permissive cloud identity and a working SSRF path is enough to pivot into everything that identity can reach.
Why This Isn’t Really an MLflow Story
MLflow is the specific vehicle here, but the underlying failure mode, an internet-facing application with SSRF exposure sitting on a cloud instance with a broadly-scoped IAM role, applies to any self-hosted tool exposed on cloud infrastructure: internal dashboards, CI/CD runners, monitoring stacks, and plenty of smaller open-source tools businesses run themselves rather than pay for a managed SaaS version of. The specific CVE gets patched; the pattern it demonstrates doesn’t go away with that one patch.
For a small or mid-sized business running any self-hosted infrastructure tooling on cloud servers, not just MLflow, the lesson is that any internet-facing service capable of making outbound HTTP requests on your behalf, a webhook system, a URL-preview feature, an image-fetching endpoint, is a potential SSRF surface, and the blast radius of a successful SSRF attack is defined entirely by what the underlying server’s cloud credentials can reach, not by what the vulnerable application itself was designed to do. Self-hosted AI and ML tooling in particular has expanded fast over the past couple of years as more businesses experiment with running their own model-tracking, vector-database, and inference infrastructure instead of relying solely on managed platforms, and a lot of that tooling was built by small open-source teams focused on functionality first, with the kind of hardened-by-default network posture a mature SaaS vendor builds in only after it’s had a security incident of its own.
Immediate Technical Fixes
If MLflow specifically is part of the stack, the immediate action is straightforward: confirm the running version and patch to 3.15.0 or later without delay, since active scanning for vulnerable instances is already underway as of this writing. But the more durable fixes apply regardless of which specific tool is involved.
Network-level metadata endpoint restrictions matter more than any single application patch. Major cloud providers support instance metadata service configurations (IMDSv2 on AWS is the well-known example) that require an explicit token-based request rather than a simple GET, specifically to make this exact class of SSRF-to-metadata-theft attack much harder to pull off even when an application-level vulnerability exists. If self-hosted tooling runs on cloud instances without this hardening enabled, that’s a gap worth closing independent of any specific CVE.
IAM role scoping is the second lever, and it’s the one businesses running their own infrastructure tend to get wrong by default rather than by mistake: it’s simply easier, when first setting up a service, to grant broad permissions and move on rather than scoping a role down to exactly what one application needs. That convenience is precisely what turns a contained SSRF bug into full credential theft. Any service exposed to the internet should run under the narrowest IAM role that lets it function, not the broadest one that’s convenient to configure once and forget.
The Organizational Half of the Fix
The technical fixes above close the door; they don’t tell you whether it was already opened before you closed it. Audit logs deserve a real look if any self-hosted tooling has been internet-facing recently, not just MLflow. watchTowr’s own advice for organizations that may have exposed instances was to review logs for indicators of compromise and verify whether credentials were actually exposed, rather than assuming a patch alone closes the loop.
Credential rotation is the step that’s easiest to skip and most important not to. A credential that was already stolen before the patch was applied is still valid until it’s rotated, regardless of how quickly the underlying vulnerability gets fixed. Any business running self-hosted tooling with cloud IAM credentials attached should treat “when did we last rotate the credentials tied to this service” as a question with a real, known answer, not something discovered for the first time during an incident. Building a routine rotation schedule, quarterly at minimum for anything internet-facing, turns “was this exposed” into a much smaller question the next time a CVE like this one lands.
The Broader Pattern for Self-Hosted Tools on Cloud Infrastructure
Self-hosting internal tools instead of paying for managed SaaS versions is a completely reasonable cost decision for a lot of businesses, but it comes with an implicit tradeoff that’s easy to overlook: the security hardening a managed vendor handles behind the scenes (metadata endpoint restrictions, IAM scoping, patch cadence, SSRF-resistant webhook handling) becomes the self-hoster’s own responsibility instead. That’s not a reason to avoid self-hosting; it’s a reason to treat “what can this server’s cloud credentials reach” as a question worth answering explicitly for every internet-facing service running on your infrastructure, MLflow or otherwise, rather than discovering the answer the way the organizations currently showing up in watchTowr’s scan logs are finding out.