The Cybersecurity and Infrastructure Security Agency added a critical vulnerability in the open-source machine learning platform MLflow to its Known Exploited Vulnerabilities catalog after telemetry confirmed attackers are actively scanning and compromising exposed instances. The flaw, tracked as CVE-2026-64849, allows unauthenticated remote attackers to trigger server-side request forgery requests from vulnerable MLflow servers to internal networks and cloud metadata services.
How the vulnerability works
MLflow is widely deployed across enterprise engineering teams to track machine learning experiments, package models, and manage deployment registries. In versions prior to 3.15.0, the platform’s outbound webhook and artifact logging mechanisms failed to adequately sanitize destination URLs. Attackers discovered that by sending crafted HTTP requests to specific API endpoints, they could force the MLflow server to make arbitrary network requests on their behalf.
Because MLflow servers often run inside cloud environments like AWS, Azure, or GCP with attached instance profiles or managed identities, this SSRF bypass turns into a direct path for credential theft. An unauthenticated attacker sends a request directing the MLflow daemon to hit internal link-local metadata addresses such as http://169.254.169.254/latest/meta-data/iam/security-credentials/ on AWS or the Instance Metadata Service on Azure. The server returns the temporary IAM role credentials or OAuth access tokens directly in its response or writes them into downloadable artifact logs.
Targeting cloud infrastructure through AI engineering tools
Security researchers observed active exploitation beginning within hours of the CVE disclosure. Attackers automated wide-scale internet scanning for exposed MLflow tracking servers, specifically probing default port configurations like 5000 and standard API routes. In several documented intrusions, threat actors used the stolen cloud credentials to establish persistence, enumerate cloud storage buckets containing proprietary training datasets, and attempt lateral movement into production Kubernetes clusters.
This incident reflects a recurring problem across the machine learning tooling ecosystem. Many data science tools were initially developed for local research environments where network isolation and user authentication were secondary considerations. As organizations pushed these platforms into cloud environments and exposed them across developer teams, they frequently neglected to put authentication proxies or strict network segmentation in front of them.
Technical analysis of the SSRF vector
The underlying flaw stems from how MLflow handles remote artifact repositories and webhook notifications. When a user or automated pipeline triggers an experiment run, the MLflow tracking server can be instructed to fetch artifacts or send completion callbacks to specified URLs. In vulnerable versions, the input parser evaluated these target endpoints without validating whether the resolved IP addresses fell within private or reserved ranges.
This permitted both direct SSRF and DNS rebinding techniques. Even if an initial check verified a public hostname, an attacker controlling the authoritative DNS server could return a public IP on the first lookup and a private metadata address on the actual HTTP request. Because the server ran with standard network privileges, it connected to internal microservices, database management interfaces, and internal container registries that were never intended to be internet accessible.
Practical remediation and hardening steps
If your organization runs MLflow, apply the following steps immediately to protect your infrastructure:
- Upgrade to version 3.15.0 or later: The MLflow maintainers patched the SSRF vector by implementing strict URL allowlisting and blocking requests to private IP ranges and cloud metadata endpoints by default.
- Enforce authentication: Never expose the MLflow tracking UI or REST API to the public internet without authentication. Place instances behind an identity-aware proxy, VPN, or enterprise single sign-on solution.
- Require IMDSv2 on cloud instances: On AWS EC2 instances hosting MLflow, enforce IMDSv2 by setting the HTTP token requirement to mandatory and reducing the hop limit to 1. This prevents SSRF requests originating from inside application containers from retrieving IAM credentials.
- Restrict IAM role permissions: Ensure that the compute instances running MLflow operate under least-privilege IAM roles. Instance profiles should not have broad administrative permissions across your cloud tenant.
- Implement strict egress filtering: Configure network security groups or firewall rules to block outbound connections from the MLflow cluster to arbitrary external IP addresses and link-local metadata endpoints.
Auditing your environment for compromise
Because exploitation leaves recognizable artifacts, security teams should conduct forensic checks across historical logs. Review web access logs for incoming POST and GET requests to tracking endpoints containing IP literals or unusual domain names in parameters. Check cloud provider audit logs (such as AWS CloudTrail or Azure Activity Logs) for unexpected API calls originating from the IP addresses of your MLflow host instances, particularly calls involving credential enumeration, secrets management, or S3 bucket downloads.
Inspect active compute instances for unexpected outbound network connections initiated by the MLflow process. Review IAM credential creation times against web server access logs to identify whether unauthorized roles were assumed. If an instance profile was potentially exposed, rotate the associated role credentials immediately and revoke any active session tokens that may have been harvested during the intrusion window.
Broader implications for AI platform security
As AI agents, model registries, and orchestration frameworks take on central roles in software delivery, they represent high-value targets for initial access brokers. Securing these platforms requires treating data science infrastructure with the same operational rigor as production web services: enforce authentication, restrict outbound network egress, and isolate metadata access.