As reported by The Hacker News, two critical-severity vulnerabilities in widely deployed open-source platforms — MLflow and FUXA — are under active exploitation as of August 18, 2026. This is not a theoretical concern; both flaws are being scanned for and exploited within hours of CVE assignment, underscoring how rapidly adversaries move once public disclosure drops.
Vulnerability Summary
| CVE | Product | CVSS | Severity | Affected Versions | Patch Available | Active Exploitation |
|---|---|---|---|---|---|---|
| CVE-2026-64849 | MLflow (Tracking Server / model-registry webhooks) | 9.3 | Critical | < 3.15.0 | Yes — upgrade to 3.15.0+ | Yes — confirmed by watchTowr honeypot telemetry |
| CVE-2026-25895 | FUXA (SCADA/HMI web platform) | 9.5 | Critical | <= 1.2.9 | Check vendor advisory | Yes — VulnCheck detected scanning from at least one IP; no RCE payload observed yet |
Why This Matters: The AI-OT Convergence Risk
These two vulnerabilities, while technically unrelated, illustrate a converging threat landscape. MLflow sits at the heart of modern MLOps pipelines — often deployed in cloud environments with access to instance metadata services (IMDS). FUXA is deployed in operational technology environments controlling physical industrial processes. Both are open-source, both are frequently exposed to the internet, and both carry the kind of unauthenticated attack surface that threat actors prioritize.
The MLflow SSRF flaw is particularly dangerous because it bypasses prior SSRF mitigations through improper handling of HTTP redirects. Attackers are using the model-registry webhook feature to proxy requests to internal cloud metadata endpoints — specifically targeting the IMDSv1 endpoint at 169.254.169.254 to extract IAM credentials, tokens, and secrets. Any organization running MLflow on AWS, GCP, or Azure with a Tracking Server exposed — even internally to other services — is at material risk of cloud account compromise.
The speed of exploitation here is the story. watchTowr reports indiscriminate scanning began within hours of CVE assignment on August 17. Defenders should assume their exposed instances have already been probed.
Who Is Most at Risk
Shield53 Recommendations
Immediate Actions — MLflow (CVE-2026-64849)
- Patch immediately: Upgrade MLflow to version 3.15.0 or later. This is the only reliable fix.
- Restrict network exposure: Ensure mlflow server is not directly internet-facing. Place it behind a VPN, private network, or authenticated reverse proxy. If it must be exposed, enforce authentication at the proxy layer.
- Harden cloud metadata service: Enforce IMDSv2 on all EC2 instances running MLflow. IMDSv2 requires session-token-based requests, which SSRF alone cannot satisfy. On GCP and Azure, apply equivalent metadata header enforcement.
- Review for compromise: Check cloud audit logs (CloudTrail, GCP Audit Logs, Azure Activity Logs) for unexpected IAM role assumptions, API calls from unfamiliar IPs, or new credential creation events originating from MLflow host instances. Rotate any credentials that may have been exposed.
- Detect exploitation: Search logs for HTTP requests from the MLflow server process targeting 169.254.169.254 or other internal RFC1918 addresses. Monitor for outbound webhook callbacks that redirect to internal IPs.
Immediate Actions — FUXA (CVE-2026-25895)
- Isolate FUXA servers: Remove any FUXA instance from public internet exposure immediately. Only ~60 are exposed — if you are one of them, treat this as an emergency.
- Upgrade: Apply the latest FUXA version available from the vendor. If no patch exists yet, consider temporarily disabling the affected component or deploying a WAF rule to block unauthenticated file write requests.
- Monitor for tampering: Check main.js and other application files for unauthorized modifications. VulnCheck observed attackers attempting to overwrite main.js with junk data — a precursor to deploying functional RCE payloads.
- OT network segmentation: Ensure FUXA and other SCADA/HMI systems are on isolated OT network segments with no direct internet egress. This is basic ICS hygiene that too many deployments still lack.
Broader Defensive Posture
- Inventory open-source AI/ML tooling: MLflow is one of many open-source MLOps tools with growing attack surface. Maintain an asset inventory of all ML infrastructure components and track their CVE exposure.
- Assume credential exposure: If you ran a vulnerable MLflow version on cloud infrastructure, assume cloud credentials were accessible. Rotate IAM keys, service account tokens, and any secrets stored in environment variables or mounted volumes on the affected host.
- Apply CISA KEV monitoring: Both vulnerabilities are strong candidates for addition to CISA's Known Exploited Vulnerabilities catalog. Monitor for KEV additions and prioritize accordingly.
The lesson here is straightforward: open-source infrastructure tools — whether for AI or OT — are not immune to critical security flaws, and the window between disclosure and exploitation is effectively zero. Organizations running MLflow or FUXA should treat these vulnerabilities as active incidents, not future patching tasks.
