Security researchers report active exploitation attempts targeting two open-source platforms: MLflow, an AI workflow and tracking tool, and FUXA, a web-based SCADA/HMI solution for industrial automation. The most urgent case involves MLflow SSRF, where attackers can leverage server-side request forgery to reach internal cloud metadata services and extract sensitive information.
Independent telemetry shared by watchTowr and VulnCheck indicates that malicious scanning started shortly after public vulnerability details were assigned in August 2026. Organizations that run these services—especially those accessible from the internet—are urged to prioritize patching and immediately review relevant logs.
What is the MLflow SSRF vulnerability?
The MLflow issue is tracked as CVE-2026-64849, with a reported CVSS score of 9.3. Researchers describe it as an unauthenticated SSRF flaw impacting MLflow versions below 3.15.0.
In practical terms, an attacker who can reach the MLflow Tracking Server can trigger the server to send HTTP requests to arbitrary internal endpoints. Instead of calling external attacker-controlled systems only, the malicious requests can be directed toward cloud metadata services—interfaces that can expose sensitive credentials used by cloud workloads.
How attackers exfiltrate cloud credentials
watchTowr reports that attackers exploited the MLflow SSRF weakness to reach cloud metadata services directly and exfiltrate cloud credentials and secrets. According to their post, they observed widespread automated scanning for exposed MLflow instances shortly after the vulnerability was assigned on August 17, 2026.
Researchers also noted that the attackers can use the MLflow model-registry webhooks in a way that effectively proxies requests through the affected system. That proxying behavior, combined with how the component handles web redirects, appears to have enabled activity that still works despite prior fixes—according to watchTowr’s analysis.
In other words, the risk is not limited to a generic “server calls a URL” scenario. The concern is that the MLflow server can be manipulated into interacting with well-known internal IP addresses and services that many cloud environments expose for credential retrieval.
Why exposure matters: scanning for reachable Tracking Servers
A key factor in these attacks is reachability. The SSRF path requires the attacker to access the MLflow Tracking Server. When MLflow is reachable from the public internet without proper compensating controls, automated scanning can quickly identify potential targets.
watchTowr’s telemetry reportedly shows attackers scanning “indiscriminately” for exposed MLflow deployments. That aligns with the pattern seen in many high-severity server-side flaws: once a dependable technique exists, attackers can scale attempts across many hosts in a short time window.
Recommended actions for MLflow operators
Given the severity and the credential theft potential, organizations running MLflow should act quickly. Based on the guidance discussed by researchers, the following steps are strongly recommended:
- Patch affected MLflow versions (MLflow versions < 3.15.0 were reported as impacted).
- Limit exposure so the Tracking Server is not directly reachable from the internet unless absolutely necessary.
- Review audit logs for signs of misuse, including unusual internal HTTP requests or webhook-related activity.
- Check whether sensitive credentials were exposed and rotate secrets if compromise is suspected.
Even if systems are patched, log review remains important because attackers may have probed or extracted data before the fix was applied.
FUXA vulnerability also draws active malicious scanning
While MLflow SSRF is the most direct credential-theft concern, VulnCheck also reported malicious scanning related to FUXA. The FUXA issue is tracked as CVE-2026-25895, with a reported CVSS score of 9.5.
Researchers describe the bug as a combination of missing authentication for a critical function and path traversal. It affects FUXA versions up to and including 1.2.9.
The reported impact is significant: an unauthenticated remote attacker may be able to write arbitrary files to the server’s file system, which could lead to remote code execution. VulnCheck’s findings suggest active probing, even though they did not yet observe deployed RCE payloads in the telemetry they shared.
What VulnCheck observed during exploitation attempts
VulnCheck detected scanning aimed at the FUXA weakness starting August 18, 2026. They reported that a single IP address was observed broadly scanning the internet for FUXA instances exposed to the public.
According to the same reporting, around 60 FUXA installations were reachable from the public internet at the time of observation, which increases the chance that opportunistic attackers will find vulnerable targets.
VulnCheck also shared an example of attacker behavior: requests attempting to overwrite main.js with junk data via the CVE-2026-25895 path traversal path. As of their assessment, no RCE payloads were dropped yet in the observed samples.
Broader context: other FUXA issues have been exploited
The FUXA story is not confined to a single CVE. VulnCheck noted that over the past year, two additional vulnerabilities associated with FUXA—CVE-2026-25939 and CVE-2023-33831—have also seen active exploitation efforts.
For CVE-2023-33831, researchers reported activity that dates back to November 2025 and has also been observed as recently as “yesterday” (relative to the time of reporting). This pattern suggests that once attackers discover an exposed service, they may continue returning as long as vulnerable instances remain online.
Security takeaway: treat exposed services as high-risk
Across both platforms, the consistent thread is reachability. When MLflow Tracking Servers or FUXA instances are exposed directly to the internet, automated scanning and exploitation attempts can begin quickly—often within hours of vulnerability assignment and public awareness.
For teams responsible for AI pipelines, model registries, and operational technology systems, this highlights the need for a unified approach to security: patch quickly, restrict network access, and maintain thorough log monitoring.
Conclusion
The reported exploitation efforts make MLflow SSRF a top priority for organizations running MLflow. Attackers appear to be scanning exposed deployments and abusing the flaw to reach internal cloud metadata endpoints, aiming to steal credentials and secrets. Alongside this, VulnCheck observed malicious probing of FUXA through CVE-2026-25895, including attempts to overwrite files via path traversal.
If you operate either platform, focus on timely patching, reducing internet exposure, and reviewing logs for suspicious request patterns. Where there is any chance credentials could have been accessed, rotate secrets promptly and validate that your environment is fully remediated.
Source: https://thehackernews.com/2026/08/attackers-exploit-mlflow-ssrf-flaw-to.html
