Published
- 4 min read
By Allan D - Editor, AI Security Wire
MLflow SSRF Flaw Under Active Attack Within Hours of CVE Release
A vulnerability in MLflow, one of the most widely deployed open source platforms for tracking machine learning experiments, is now being actively exploited in the wild. CVE-2026-64849 is an unauthenticated server-side request forgery flaw with a CVSS score of 9.3, and researchers say attackers started scanning for it within hours of the advisory going public.
MLflow sits at the center of a lot of ML pipelines. Teams use it to log experiments, register models, and manage the handoff from training to deployment, often on infrastructure that also has access to cloud credentials, internal APIs, and other sensitive services. That makes an SSRF bug in MLflow more dangerous than it might look at first glance. It’s not just about the tracking server itself. It’s about everything the tracking server can reach.
How the flaw actually works
The bug lives in MLflow’s model registry webhook feature. When someone configures a webhook, MLflow validates the target URL through a function called _validate_webhook_url to make sure it isn’t pointing somewhere it shouldn’t, like an internal address or a cloud metadata endpoint. That check happens fine.
The problem is what happens afterward. The delivery code that actually sends the webhook request follows HTTP redirects, but it never re-validates where a redirect ends up. So an attacker registers a webhook pointing at an ordinary, harmless-looking URL that passes validation, then has that URL respond with an HTTP 302 redirect to something like the AWS metadata service at 169.254.169.254 or an internal-only address. MLflow follows the redirect and the server ends up acting as a proxy into its own internal network, with the response reflected right back to the attacker through the webhook test endpoint.
WatchTowr researcher Yordan Ganchev, whose team reported the active exploitation, described it as bypassing prior fixes specifically because of how redirect handling was never pinned to the originally validated address. Beyond straightforward information disclosure, attackers can also use 307 and 308 redirects to perform blind writes against internal POST-based services, which opens the door to interacting with management endpoints that were never meant to be internet-reachable.
Attackers moved fast
This is the part that should get operators’ attention. According to watchTowr Intel, its global honeypot network, which the company calls Attacker Eye, picked up scanning and exploitation attempts against exposed MLflow instances within hours of CVE-2026-64849 being assigned on August 17, 2026. The activity was specifically targeting cloud-hosted MLflow deployments, probing for credentials and secrets tied to well-known internal IP ranges and metadata services.
That kind of turnaround isn’t unusual anymore for anything touching AI or ML infrastructure. Attackers have gotten good at watching CVE feeds and standing up scanners the same day a flaw is disclosed, especially when the payoff is direct access to cloud credentials rather than something that requires further work to monetize.
Why this matters beyond MLflow
The underlying pattern here is worth paying attention to on its own. SSRF through unpinned redirects is a known class of bug, but it keeps showing up in ML tooling because a lot of these platforms were built for internal, trusted environments and only later got exposed to the internet as teams scaled up. Validation logic that checks a URL once, at submission time, and then trusts wherever the server ends up connecting later is a recurring weak point, and MLflow isn’t the first ML platform to have shipped it.
Organizations running MLflow, particularly anywhere it’s reachable from outside a tightly controlled network, should treat this one as urgent. The fix landed in MLflow 3.15.0, which patches the redirect handling so the delivery step re-validates the final destination rather than trusting the original check.
What to do now
Patch to 3.15.0 or later without delay. If the tracking server doesn’t need to be internet-facing, put it behind a VPN or internal network boundary instead, since that removes the exposure regardless of patch status. Go back through webhook configuration and delivery logs looking for unexpected outbound requests, particularly anything touching metadata service IP ranges. And if there’s any chance the server had reachable cloud credentials, rotate them. Assuming the worst didn’t happen is a bad bet when a honeypot network is already showing active scanning against the exact flaw in question.
References
Frequently Asked Questions
- What is CVE-2026-64849?
- It's a critical, CVSS 9.3 unauthenticated server-side request forgery vulnerability in MLflow's webhook delivery system. It affects all MLflow versions before 3.15.0 and lets an attacker force a vulnerable server to issue HTTP requests to internal cloud metadata endpoints, exposing credentials and secrets.
- How does the bypass work?
- MLflow validates a submitted webhook URL once, at the time it's tested. The flaw is that the code path which actually delivers the request follows HTTP redirects without re-checking where they lead. An attacker points the webhook at an ordinary URL that returns a 302 to something like a cloud metadata address, and MLflow follows it straight through.
- Is this being actively exploited?
- Yes. WatchTowr Intel says its global honeypot network detected scanning and exploitation attempts against exposed MLflow instances within hours of the CVE being assigned on August 17, 2026, specifically probing for cloud credentials and internal secrets.
- What should MLflow operators do?
- Upgrade to MLflow 3.15.0 or later immediately, restrict network access to the tracking server so it isn't reachable from the open internet, review webhook configuration and delivery logs for suspicious outbound requests, and rotate any cloud credentials that may have been reachable from the metadata service.