MLflow SSRF, FUXA Auth Flaws Actively Exploited

MLflow manages experiment runs, tracks model versions, and stages artifacts. FUXA sits between network-connected control systems and the operator screens used to watch what’s happening on the floor. Both are designed to accept connections from the network. Two critical vulnerabilities — one in each — are now under active attack.

Reports published August 18 by watchTowr and VulnCheck document active exploitation of the MLflow flaw and confirmed malicious scanning against exposed FUXA instances.

CVE-2026-64849 — MLflow SSRF, CVSS 9.3

The flaw is a server-side request forgery in MLflow versions before 3.15.0. An attacker with network access to the MLflow tracking server can craft a request that the server executes on their behalf, reaching internal endpoints that the attacker cannot reach directly.

In cloud deployments — which describes most production MLflow installations — those internal endpoints include the instance metadata service. On AWS, a request to the IMDS endpoint returns the IAM role credentials attached to the hosting instance without additional authentication. watchTowr confirmed attackers are using this path to extract cloud credentials and secrets as of August 2026.

The fix is in MLflow 3.15.0. Upgrade. If that isn’t operationally immediate, restrict outbound network access from the MLflow tracking server to prevent it from reaching metadata endpoints, and audit the IAM role permissions attached to the hosting instance.

CVE-2026-25895 — FUXA ≤ 1.2.9, CVSS 9.8

FUXA is an open-source web-based SCADA and HMI tool used in smaller industrial sites where purpose-built historians are overkill. Versions 1.2.9 and below have two compounding flaws: missing authentication on a critical function, and a path traversal. Together they allow an unauthenticated remote attacker to write arbitrary files to the host filesystem — including the application’s own main.js.

VulnCheck confirmed active scanning against FUXA instances beginning August 18. Approximately 60 FUXA deployments are reachable from the public internet. For context: FUXA sits in front of the physical layer — valve positions, conveyor states, sensor readings. Getting code into main.js on a machine in that role is a different category of failure than a web application defacement.

For FUXA: network exposure is the immediate risk. If your FUXA instance is internet-reachable, remove that exposure before you address the patch question — segmentation is faster. Then follow the upstream advisory for patching.

The overlap worth noting

Both CVEs require no authentication and no user interaction. Both score critical. Neither requires the other to matter.

But ML pipelines feeding operational analytics alongside FUXA-class HMI tools are common in the same facility infrastructure right now. A stolen IAM credential from CVE-2026-64849 is the kind of cloud foothold that can be leveraged into adjacent systems on the same network — including OT-adjacent segments. The two vulnerabilities don’t combine automatically. The network topology of any given environment determines the actual exposure.

Patch MLflow. Segment FUXA. Do both this week.

---

Coverage of active exploitation in adjacent tooling: TWINLOOT Python Implant Hides C2 in SharePoint | CISA Adds Windows Task Host to KEV as Ransomware Gangs Move In | ICS/OT topic hub