MLflow SSRF Bug Is Being Exploited to Loot Cloud Metadata Credentials Hours After Disclosure

Attackers started scanning the internet for exposed MLflow servers within hours of CVE-2026-64849 being assigned on August 17, 2026, and watchTowr's global honeypot telemetry shows they are not just fingerprinting. They are reaching cloud metadata services through the vulnerable host and exfiltrating credentials and secrets. The flaw carries a CVSS score of 9.3, requires no authentication, and affects every MLflow release below 3.15.0.

A second unauthenticated critical flaw is moving in parallel. CVE-2026-25895 (CVSS 9.5) in FUXA, the open-source web-based SCADA/HMI package used in OT and industrial automation, allows a remote attacker to write arbitrary files to the server filesystem and reach remote code execution. VulnCheck detected malicious scanning against it starting August 18, 2026. Different stacks, same story: unauthenticated pre-auth bugs in infrastructure that sits outside the normal patch inventory.

How the MLflow SSRF Works

The vulnerability lives in MLflow's model-registry webhook handling. According to Yordan Ganchev, principal threat intelligence specialist at watchTowr, the bug lets an attacker proxy requests through the affected system and interact with internal services. Anyone who can reach the Tracking Server (the `mlflow server` process) can make that server issue HTTP requests to arbitrary internal endpoints on the attacker's behalf.

The detail that matters for defenders: this bypasses prior fixes because of how MLflow handles web redirects. Earlier hardening validated the initial webhook destination but did not re-validate after a redirect, so an attacker registers a webhook pointing at an external host they control, that host returns a 3xx redirect to an internal address, and MLflow follows it. Allowlist logic that only inspects the first hop never sees the final target.

Ganchev noted that attackers are targeting "well-known internal IP addresses and services." In practice that means the cloud instance metadata endpoints at 169.254.169.254 on AWS and GCP, and 169.254.169.254 with the Metadata header on Azure. On an EC2 host still permitting IMDSv1, an unauthenticated GET against the security-credentials path returns temporary IAM keys for whatever role the MLflow instance carries. ML training infrastructure tends to carry generous roles: S3 read and write across data lakes, ECR push, sometimes Secrets Manager. The SSRF is not the prize. The IAM role is.

Why MLflow Servers Are Exposed in the First Place

MLflow ships with no authentication by default. The Tracking Server is designed to be reachable by every data scientist, notebook, and training job in the org, so teams stand it up on a public load balancer or a permissive security group, often outside the workflow that governs production services. It gets classified as a research tool rather than production infrastructure, which means no WAF, no egress filtering, and no patch SLA. Meanwhile it holds experiment metadata, artifact paths, registry credentials, and a cloud IAM role.

That is the pattern to internalize. AI and ML tooling has become production infrastructure with the security posture of a lab environment. Mass scanning arriving inside a day of CVE assignment tells you attackers already understand this and have the target lists pre-built.

The FUXA Side: Scanning Now, Payloads Later

VulnCheck observed a single IP address broadly scanning the internet for vulnerable FUXA instances. Caitlin Condon, VP of research at VulnCheck, reported that "the attacker request attempts to overwrite main.js with junk data via the CVE-2026-25895 path traversal" and that no RCE payloads have been dropped yet.

Read that as reconnaissance, not restraint. Overwriting main.js with garbage is a cheap oracle: if the write succeeds, the target is confirmed vulnerable and the attacker banks it for later. The side effect is that it breaks the HMI's front-end for operators, which is a nontrivial availability hit on a live process-control console. Weaponized payloads typically follow validated target lists by days.

The exposed population is small at roughly 60 internet-facing installations, but each one is an operator interface to physical process control. FUXA also has history: CVE-2026-25939 and CVE-2023-33831 have both drawn active exploitation over the past year, with activity against the 2023 bug dating back to November 2025 and continuing through this week. Attackers who scan for FUXA are running a persistent campaign against the product, not a one-off.

What to Do Now

• Upgrade MLflow to 3.15.0 or later. Every version below that is affected by CVE-2026-64849.
• Inventory every MLflow Tracking Server, including ones stood up by data science teams outside your CMDB. Anything reachable from the internet is presumed targeted.
• Enforce IMDSv2 with a hop limit of 1 on all ML and data-processing instances, and block egress to 169.254.169.254 from application containers that have no reason to query metadata.
• Rotate the IAM role credentials, API keys, and registry secrets associated with any exposed MLflow host. Assume theft rather than waiting for proof.
• Review MLflow audit logs and cloud provider logs for webhook registrations you did not create, and for API calls from the instance role originating outside its normal region or service pattern.
• Upgrade FUXA past 1.2.9 and pull it off the public internet entirely. SCADA/HMI belongs behind a VPN or jump host, not on a routable IP.
• Check FUXA hosts for a corrupted or unexpectedly modified main.js, which indicates the CVE-2026-25895 probe already landed.

Bottom Line

Two unauthenticated CVSS 9-plus bugs, both under active attack, both in software that traditional vulnerability management tends to miss. The MLflow flaw is the more urgent of the pair because exploitation is confirmed, credential theft is the confirmed objective, and the blast radius extends from one server to the entire cloud account behind its IAM role. Patch to 3.15.0, enforce IMDSv2, and rotate. The FUXA scanning is still at the reconnaissance stage, which gives you a narrow window to get those 60 consoles off the public internet before payloads follow the target list.