An Engineer Stood Up a Dashboard, Just for the Team
An engineer at a mid-sized company spins up an MLflow tracking server on an internal VM so the data science team can log experiments and compare model runs. MLflow does not ask for a username or password during setup, so none gets configured, and the server goes live behind what everyone assumes is a private network. In a factory a few hundred kilometres away, an operations engineer does something similar: they stand up FUXA, an open-source SCADA and HMI platform, to give the team a browser-based view of production-line tags. Neither system was built to be reachable from the open internet, and neither team checked.
In the week of 18 August 2026, both assumptions turned out to be wrong at once. MLflow, an experiment-tracking platform hosted under LF Projects at the Linux Foundation, and FUXA, an unrelated industrial control system tool, each disclosed a critical, unauthenticated-by-default vulnerability - and in both cases attackers had working exploits within hours of the disclosure going public, not weeks. Two different codebases, two different industries, two different teams who never coordinated with each other. What they share is a single design decision made independently, years apart, for the same reason: it is faster to ship a tool with authentication off than on.
MLflow's Flaw Turns a Redirect Into a Credential Theft
The MLflow vulnerability, tracked as CVE-2026-64849, carries a CVSS score of 9.3. It is a webhook-URL validation bypass: MLflow lets users register webhooks that fire on events such as a completed training run, and it checks the destination URL before allowing it, to stop the server from being pointed at internal addresses. Attackers found they could defeat that check by pairing an HTTP redirect with DNS rebinding - registering a webhook to an address that passes validation, then having it resolve, at request time, to an internal IP the validator never saw. GitLab published a security advisory on the flaw, and the exploit was corroborated independently by cybersecurity outlets including cybersecuritynews, cyberpress, and GBHackers.
The payoff for an attacker is server-side request forgery: the MLflow server itself becomes the one making the request, from inside whatever network it lives on. That lets an attacker reach internal services that were never meant to face outward, and critically, cloud instance-metadata endpoints on AWS, Azure, and GCP - the internal addresses that hand out temporary credentials to the machine that asks. Because MLflow tracking servers commonly run without authentication in real deployments, nothing stops an outside attacker from making that first request. The Hacker News reported on 18 August 2026 that active exploitation began within hours of disclosure.
FUXA's Gap Lets Outsiders Write Files on Plant Systems
FUXA is an open-source SCADA and HMI platform - the kind of software that gives plant operators a browser window onto the equipment actually running a production line. Its vulnerability, CVE-2026-25895, scores even higher than MLflow's at 9.5, and the mechanism is blunter: missing authentication combined with a path-traversal flaw. An unauthenticated attacker can send a request that escapes the directory FUXA expects to write into and place a file anywhere on the underlying filesystem they choose.
Arbitrary file write is not a data-exposure bug, it is a foothold. An attacker who can write files wherever they like on a system that talks to industrial equipment can plant executable code and achieve remote code execution, which means full control of the host running the HMI - and, depending on how that host is wired into the plant floor, a path toward the control systems themselves. As with MLflow, The Hacker News and the same corroborating outlets reported active exploitation beginning within hours of public disclosure, in the same week as the MLflow advisory.
The Common Thread Is Not the Code, It Is the Default
MLflow and FUXA share no code, no maintainers, and no market. One tracks machine learning experiments, the other visualizes industrial control systems, and they were disclosed independently in the same week purely by coincidence of timing. What they share is a default: ship without authentication, because it is the fastest way to get a tool running for a small internal team, and because the team assumes the network around it is private. That assumption is the entire attack surface.
The same default sits underneath a large share of internal tooling that owners never personally inspect: MLOps dashboards, monitoring stacks, internal admin panels, and SCADA/HMI systems across manufacturing. Each one was likely stood up quickly, by someone competent, solving a real problem, who never circled back to turn authentication on because nothing forced them to. The gap between assumed-private and actually-reachable - whether through direct internet exposure or, as with MLflow, through an SSRF pivot from a system that is reachable - is exactly where both of these exploits landed, and it is where the next one will land too.
Hours to Exploitation Is Now the Real Patch Window
For any EU or UK business running MLOps pipelines - increasingly common as companies deploy their own ML and AI infrastructure - or any industrial or manufacturing business running SCADA or HMI systems, the practical response is an audit, not a policy memo. Every internal tool needs a direct answer to one question: is authentication actually enabled, not assumed to be, and is the tool actually unreachable from outside the network it is supposed to live on. MLflow and FUXA both show that the honest answer is often no, and that nobody finds out until it is exploited.
The other adjustment is the clock. Both flaws went from public disclosure to active exploitation in hours, not the weeks that patch cycles have traditionally assumed. For EU-based industrial operators specifically, this is not only a technical problem: NIS2 obligations apply to digital infrastructure providers and, notably, to manufacturing and industrial operators running OT and SCADA systems, which makes an unpatched, unauthenticated HMI a compliance failure as well as a security one. The fix is not exotic - turn authentication on, patch on disclosure day, assume nothing behind your firewall is actually private - but it has to happen before the exploit does, and this week that gap was measured in hours.
Read next: A Vendor Breach Your DORA Register Can't Explain | Shell and Philips Lost Blueprints, Not Passwords
