Your MLflow instances are leaking cloud credentials right now. Attackers aren't waiting for you to patch CVE-2026-64849. They're already inside, targeting the metadata endpoints that hand over AWS keys, Azure tokens, and whatever else you've stored.
What Happened
Two open-source platforms used in production environments, MLflow and FUXA, shipped with exploitable vulnerabilities that attackers are actively using. MLflow's server-side request forgery (SSRF) flaw (CVE-2026-64849, CVSS 9.3) lets attackers force your MLflow instance to make requests to internal cloud metadata endpoints and exfiltrate the responses. FUXA's path traversal bug (CVE-2026-25895, CVSS 9.5) allows remote code execution through directory manipulation.
Both vulnerabilities affect specific version ranges: MLflow versions below 3.15.0 and FUXA versions 1.2.9 and earlier. WatchTowr detected active exploitation of the MLflow flaw in the wild, with attackers systematically targeting cloud credential endpoints. VulnCheck reported scanning activity against approximately 60 publicly exposed FUXA installations.
Timeline
The sequence matters because it shows how quickly theoretical vulnerabilities become operational attacks:
Pre-disclosure: Vulnerabilities existed in production code, likely for months or years before discovery.
Public disclosure: Security researchers published CVE details and proof-of-concept code for both vulnerabilities.
Exploit development: Attackers weaponized the MLflow SSRF within days, building automated tools to scan for vulnerable instances and extract credentials.
Active exploitation: WatchTowr observed credential exfiltration attempts against MLflow deployments. VulnCheck detected scanning activity targeting FUXA installations.
Current state: Patches are available (MLflow 3.15.0+), but unpatched instances remain exposed. The attack window is open until you close it.
Which Controls Failed or Were Missing
Input validation on URL parameters: MLflow accepted user-controlled URLs without sufficient validation, allowing attackers to specify internal metadata endpoints like http://169.254.169.254/latest/meta-data/iam/security-credentials/. The application made those requests and returned the results.
Network segmentation: MLflow instances had direct access to cloud metadata services. If you're running MLflow on EC2, it can reach the instance metadata endpoint by default; there's no network boundary preventing that request.
Egress filtering: No controls blocked outbound connections to attacker-controlled servers where stolen credentials were sent. The application could make arbitrary HTTP requests to any destination.
Vulnerability scanning and patch management: Organizations running affected versions hadn't implemented continuous scanning or rapid patching processes. The gap between patch availability and patch deployment created the exploitation window.
Monitoring and detection: Most teams lack visibility into unusual metadata endpoint access patterns. When MLflow suddenly starts querying 169.254.169.254, nobody gets an alert.
Least privilege for service accounts: The credentials accessible through the metadata endpoint likely had broader permissions than MLflow needed. If those credentials can only read from a specific S3 bucket, the blast radius shrinks.
What the Relevant Standard Requires
PCI DSS v4.0.1 Requirement 6.3.1: Identify security vulnerabilities using reputable sources and assign a risk ranking to newly discovered vulnerabilities. You need a process that catches CVEs like these within days of disclosure, not weeks.
PCI DSS v4.0.1 Requirement 6.3.3: Install relevant security patches within one month of release for critical systems. MLflow handling production data qualifies. One month is your maximum window; active exploitation makes it urgent to move faster.
OWASP ASVS v4.0.3 Section 5.2 (Sanitization and Sandboxing): Verify that the application sanitizes, disables, or sandboxes user-supplied Scalable Vector Graphics (SVG) scriptable content, and more broadly, that URL parameters used in server-side requests are validated against allowlists. The MLflow SSRF violates this completely.
NIST 800-53 Rev 5 SI-3 (Malicious Code Protection): Deploy malicious code protection mechanisms at information system entry and exit points. Egress filtering would have blocked credential exfiltration even if the SSRF succeeded.
ISO 27001 Control 8.8 (Management of Technical Vulnerabilities): Obtain timely information about technical vulnerabilities, evaluate exposure, and take appropriate measures. This means you need a subscription to vulnerability feeds and a documented response process.
SOC 2 Type II CC7.1 (System Monitoring): The entity uses detection and monitoring procedures to identify anomalies. Unusual access to metadata endpoints or unexpected outbound connections should trigger alerts.
Lessons and Action Items for Your Team
Patch immediately: Upgrade MLflow to 3.15.0 or later. Upgrade FUXA beyond 1.2.9. If you can't patch in the next 48 hours, take the instances offline or put them behind a VPN. Don't wait for your regular patch cycle.
Audit your exposure: Run curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/ from your MLflow instance. If you get credentials back, assume they're compromised. Rotate them now.
Block metadata endpoint access: Use iptables or security groups to prevent your MLflow instances from reaching 169.254.169.254. You can also disable IMDSv1 and require IMDSv2 with a hop limit of 1, which blocks SSRF attacks.
Implement egress filtering: Your application servers shouldn't make arbitrary outbound connections. Allowlist the specific external services they need (package repositories, API endpoints) and block everything else.
Set up SSRF detection: Monitor for requests to RFC 1918 addresses, loopback interfaces, and cloud metadata endpoints. Alert when applications make unexpected internal requests.
Scope your service credentials: Review the IAM roles and policies attached to your MLflow instances. Grant only the specific S3 buckets, databases, and services the application actually uses. If attackers steal overprivileged credentials, they get more access.
Build a 24-hour CVE response process: When a critical vulnerability drops in software you run, you need a documented process to assess impact, test patches, and deploy within 24 hours for actively exploited flaws. One month is too slow when exploitation starts immediately.
The MLflow and FUXA incidents show that open-source tools in your ML and SCADA pipelines are attack surfaces. Treat them like any other production system: patch fast, monitor closely, and assume breach until you verify otherwise.
