
Active Exploitation of MLflow SSRF Bug Leads to Cloud Credential Theft
A server-side request forgery flaw in the MLflow machine learning platform is being exploited by attackers to steal cloud credentials and secrets, putting data and infrastructure at risk.
Attackers are actively exploiting a vulnerability in MLflow, an open-source platform used to manage the full lifecycle of machine learning projects, to steal cloud credentials and other secrets. MLflow helps data teams track experiments, package code, and deploy models, and it often runs on cloud servers with access to sensitive resources. The flaw being abused is a server-side request forgery (SSRF) issue, which lets an attacker force the MLflow server to make unintended requests to internal systems.
In a server-side request forgery attack, the attacker sends a specially crafted request that causes the vulnerable server to fetch data from a location chosen by the attacker. This can include private network addresses that are normally not reachable from the outside. In cloud environments, one of the most valuable targets is the cloud metadata service. That is a special internal web address inside a cloud virtual machine that provides temporary access keys and other setup information. Because MLflow runs with the permissions of that virtual machine, an attacker who can trigger an SSRF can ask MLflow to contact the metadata service and retrieve those temporary keys. Those keys can then be used to access cloud storage buckets, databases, and other services associated with the same cloud account.
The stolen credentials are not just abstract data. They can allow an attacker to read, copy, or delete files stored in cloud storage, spin up new servers to mine cryptocurrency, or access customer databases. For website owners and businesses that rely on cloud hosting, this type of compromise can lead to data breaches, service disruption, and unexpected bills. Even if the initial MLflow instance does not contain sensitive data itself, its position inside a cloud account makes it a stepping stone to more critical systems. The automation of this attack is particularly concerning: attackers can scan the internet for exposed MLflow servers, send the crafted request, and collect credentials within seconds.
Why are MLflow deployments such an attractive target? First, MLflow is open-source, meaning its code is public and widely studied, so vulnerabilities can be discovered and exploited by anyone. Second, many data science teams expose MLflow to the internet without proper authentication or network restrictions, often because they want remote access for convenience. Third, the platform is designed to interact with cloud storage and compute resources, so it frequently holds cloud credentials or has the ability to obtain them. These factors combine to make unpatched or misconfigured MLflow instances a low-effort, high-reward target for attackers.
The best defense is to treat MLflow like any other production service. Apply security updates as soon as they are available, and keep the software isolated from the public internet. Put it behind a virtual private network (VPN) or a reverse proxy with strong authentication so that only authorized team members can reach it. Do not store cloud access keys directly in MLflow configuration files; instead, use environment variables or a secrets manager. Monitor outbound network connections from MLflow for unusual requests to internal addresses. Finally, block access to the cloud metadata service from within MLflow by using firewall rules or cloud provider settings that restrict that special address to only trusted processes. For organizations that need help hardening their cloud infrastructure, AEU-I provides security-first IT and consulting services that can review configurations, restrict access, and monitor for suspicious activity.
How to Protect Yourself
- If you use MLflow or any similar tool for your website or data work, turn on automatic updates and install the latest version right away.
- Do not leave administrative tools like MLflow open on the public internet; hide them behind a login page or a private network that only your team can access.
- Never write passwords or secret keys directly in files or code; use a password manager or a secure vault instead.
- Regularly check your cloud provider's activity log and billing for any unfamiliar services, new servers, or unexpected charges.
- Ask your hosting or IT provider to block access to the internal metadata address (a special web address that hands out temporary keys) from your web applications.