# When Your AI Experiment Tracker Hands Attackers Your Cloud Keys
MLflow was designed to make machine learning teams move faster — log experiments, track artifacts, compare model runs, deploy endpoints. Security, historically, was someone else's problem. That oversight is now being exploited in the wild.
Security firms watchTowr and VulnCheck have independently confirmed active scanning and exploitation targeting a critical server-side request forgery (SSRF) flaw in MLflow, the open-source AI experiment tracking platform that sits at the center of most modern ML pipelines. Alongside it, FUXA — an open-source SCADA/HMI system used in industrial automation and operational technology environments — carries its own critical flaw now drawing attacker attention. Two vulnerabilities, two very different ecosystems, both heading in the same direction.
## The SSRF Play, Explained for People Who Haven't Seen It a Hundred Times
SSRF is a deceptively simple attack class. An application that fetches remote URLs on behalf of users can be tricked into fetching internal ones instead — including the cloud metadata endpoint sitting at 169.254.169.254 on virtually every AWS, Azure, and GCP instance ever provisioned.
Hit that endpoint from a vulnerable server and you often walk away with IAM credentials tied to whatever role the instance is running as. In a well-misconfigured environment — which describes most data science infrastructure — that role has permissions the team never thought twice about because "it's just the ML server."
MLflow's SSRF vulnerability creates exactly this path. An unauthenticated attacker who can reach an exposed MLflow instance can coerce it into making requests to the metadata service, extracting temporary cloud credentials. From there, the blast radius depends entirely on what the attached IAM role can do: read S3 buckets full of training data, access secrets in Parameter Store or Secrets Manager, pivot to other services, or quietly establish persistence.
WatchTowr and VulnCheck's findings confirm this isn't theoretical — scanning and exploitation attempts are active.
## Why MLflow Is a Soft Target
The uncomfortable truth about MLflow deployments is that they were never supposed to be internet-facing, and a significant portion of them are anyway.
Data science teams spin up MLflow tracking servers quickly, often on cloud instances or Kubernetes clusters with permissive ingress rules because the immediate priority is getting experiment logging working before the next model training run. The MLflow UI is convenient — being able to pull it up from anywhere is convenient. Security controls come later, which frequently means never.
Shodan and Censys have long shown thousands of MLflow instances publicly accessible without authentication. The default MLflow server ships with no auth layer; enabling it requires deliberate configuration steps. Many organizations running MLflow internally behind corporate firewalls may also be surprised to learn their Kubernetes LoadBalancer service accidentally exposed the tracker externally when the cluster's network policies were last updated.
The SSRF finding compounds this because it converts a "we're only exposing read-only experiment data" assumption into a full cloud credential compromise. You're not just leaking your training runs — you're handing over the keys to whatever the underlying host can access.
## The FUXA Dimension: When Industrial Systems Join the Party
FUXA's appearance in the same vulnerability disclosure cycle is worth pausing on. FUXA is a web-based SCADA and HMI platform used in operational technology environments — factory floors, building management systems, industrial automation setups where the consequence of a compromise isn't stolen credentials but potentially physical-world disruption.
The OT threat landscape has been escalating for years, and open-source SCADA tooling represents a specific gap: it democratizes industrial automation capabilities but often lacks the security scrutiny that commercial vendors (under regulatory pressure) have been forced to adopt. FUXA instances exposed to the internet — and reports suggest some are — present an entirely different risk profile than a misconfigured MLflow tracker.
Active scanning against FUXA signals attacker reconnaissance of industrial targets, even if exploitation doesn't immediately translate to operational disruption. Understanding the layout of a SCADA network, identifying connected field devices, mapping historian servers — all of that has value in future attack planning.
That both MLflow and FUXA are surfacing in the same exploitation wave is less coincidence than it is a reflection of how attacker tooling now sweeps entire vulnerability classes across ecosystem boundaries simultaneously.
## What Defenders Need to Do Right Now
For MLflow operators, the immediate priorities are:
For FUXA operators, the question is whether your HMI is reachable from untrusted networks at all, which it should not be under any industrial security framework worth its name.
---
## HackWire Analysis
The MLflow exploitation story fits into a pattern that has been building for two years: AI and ML infrastructure is being treated as a development tool rather than a production attack surface, and attackers have noticed.
This isn't just about MLflow. The broader AI tooling stack — experiment trackers, model registries, feature stores, data labeling platforms, notebook servers — has expanded rapidly into organizations whose security teams haven't fully caught up with what these systems are, what they can access, and what happens when they're compromised. The attitude in many ML engineering teams is that these are internal tools, not customer-facing services, so the usual security review cycles don't apply. That reasoning worked better when cloud credentials weren't a two-request API call away from any server that can make outbound HTTP requests.
The SSRF-to-metadata-endpoint attack chain is not new — it's the same technique that contributed to high-profile breaches going back nearly a decade. What's new is the target ecosystem. Defenders who have hardened their web applications and APIs against SSRF haven't necessarily asked whether their data science infrastructure has the same controls applied.
The FUXA angle deserves more attention than it will probably get. OT security incidents rarely make headlines until something stops moving or stops working, and reconnaissance activity against industrial systems rarely surfaces at all. The fact that VulnCheck flagged active scanning against FUXA matters — it suggests someone is building a target list, not just running opportunistic bots.
The practical question for security teams this week is: do you know every MLflow and FUXA instance running in your environment, and do you know what cloud credentials and OT networks each of them can reach? Most teams don't. That's the gap these exploits are designed to fall through.
— HackWire Editorial
---
## Related Coverage