Hackers Are Actively Attacking MLflow and FUXA to Steal Cloud Secrets

Key points

• Researchers at watchTowr and VulnCheck are seeing active exploitation of critical bugs in MLflow, an open-source platform used to manage AI experiments, and FUXA, an open-source control panel used to run factory equipment.
• Attackers are abusing an MLflow flaw to make the server fetch data from internal cloud addresses, tricking it into handing back cloud login credentials.
• FUXA runs industrial machinery, so a break-in can affect physical equipment on a factory floor, not just data on a server.
• Both products are free, self-hosted software, meaning the fix falls on whoever installed them, not a vendor pushing an automatic update.
• The activity was flagged in reports picked up by The Hacker News, with scanning traffic hitting exposed instances on the public internet.

Two open-source tools sitting quietly inside a lot of companies are getting hammered right now, and most of the people running them probably do not know it.

One is MLflow, a platform data scientists use to track their machine-learning experiments. The other is FUXA, a web dashboard that engineers use to monitor and control industrial equipment, the sort of software that sits between an operator's browser and a real pump or conveyor belt.

Both have critical vulnerabilities. Both are being scanned and hit on the open internet. That combination is the whole story.

What are attackers actually doing?

They are hunting for exposed MLflow and FUXA servers and breaking in to steal cloud credentials or gain a foothold. The MLflow bug is a server-side request forgery flaw, meaning an outsider can trick the MLflow server into making web requests on their behalf, from inside the victim's network.

In practice, that is a gift. Cloud servers on Amazon Web Services, Google Cloud and Microsoft Azure all expose an internal address that hands out short-lived login keys to whatever code is running on the machine. If an attacker can make the MLflow server ask that internal address for keys, the server dutifully fetches them and sends them back out. The attacker now has cloud credentials belonging to the MLflow box.

From there it is the usual playbook: poke around storage buckets, list databases, look for anything with the word "prod" in the name.

Why does FUXA matter separately?

FUXA controls physical stuff. It is a SCADA and HMI tool, industry jargon for the software that lets a human operator watch and adjust machinery, valves, temperature sensors, motor speeds, from a browser.

A broken FUXA server is not just a data problem. The failure mode here is an attacker who can flip switches on a factory floor, or at minimum blind the people who are supposed to be watching those switches. Anyone running FUXA exposed to the internet should assume they are already being probed.

Should ordinary people be worried?

Not directly, but indirectly, yes. If your employer's data science team runs MLflow, or your utility runs FUXA, a break-in there can leak customer data or disrupt services you rely on. There is nothing for a home user to patch.

The people who need to act today are the platform and operations teams running these tools.

What should teams do now?

Get both off the public internet. Neither of these tools was designed to sit unauthenticated on the open web, and yet a fair number of them do. Put them behind a VPN or a proper identity gateway, patch to the latest release, and rotate any cloud credentials that the MLflow host has touched in the last month.

One thing the post-mortem will say, when it gets written: nobody knew MLflow was internet-facing until the alerts fired.

The operational takeaway is boring and correct. Internal tools belong on internal networks.