FHN 
A critical security flaw in MLflow is being targeted by attackers, putting internet-facing machine learning infrastructure at risk.
MLflow is widely used by data science and machine learning teams to track experiments, manage models, and support model deployment. Security teams should pay particular attention to publicly accessible MLflow servers because SSRF vulnerabilities can allow attackers to make requests from the vulnerable server into otherwise protected environments.
Critical SSRF Vulnerability in MLflow
The vulnerability is a server-side request forgery (SSRF) issue. In an SSRF attack, an attacker abuses a server to send requests to destinations that should not normally be accessible from the internet.
The affected MLflow functionality involves webhook testing. An attacker can abuse the server-side request mechanism to reach internal services and potentially retrieve sensitive information.
The risk is particularly significant when MLflow is deployed in cloud environments, where internal metadata services may expose temporary credentials or other configuration details.
Why the Vulnerability Is Dangerous
An exposed MLflow server can become a bridge between an external attacker and internal cloud infrastructure.
Depending on the environment, successful exploitation could allow attackers to:
- Access cloud metadata services
- Obtain temporary cloud credentials
- Query internal applications and services
- Reach localhost-only administrative interfaces
- Discover information about the host environment
- Potentially use stolen credentials for further attacks
Cloud environments such as AWS, Azure, and Google Cloud can be especially sensitive because their metadata services may provide access tokens and other temporary credentials.
Redirects Can Complicate SSRF Protection
One challenge with SSRF defenses is ensuring that URL validation remains effective throughout the entire request process.
A destination that appears safe during the initial validation may redirect the server to a private address or cloud metadata endpoint afterward. DNS resolution can introduce another problem if an attacker is able to change where a hostname points after the initial security check.
These scenarios demonstrate why SSRF protection needs to validate the complete request path rather than relying only on the first destination.
Attackers Are Scanning Exposed Systems
Security monitoring has shown that attackers are actively searching for vulnerable MLflow deployments exposed to the internet.
The speed of the activity is a reminder that newly disclosed vulnerabilities in internet-facing software can be discovered and tested quickly through automated scanning.
Organizations should therefore avoid assuming that an exposed MLflow server will remain unnoticed simply because it is hosted on a non-standard environment or is not widely known.
What Organizations Should Do
Security teams operating MLflow should prioritize the following actions:
- Upgrade MLflow to a version containing the appropriate security fixes.
- Remove direct internet exposure where public access is not required.
- Place MLflow behind an identity-aware proxy or VPN.
- Restrict outbound network access from MLflow servers.
- Block access to cloud metadata endpoints unless explicitly required.
- Review server and network logs for unusual webhook testing activity.
- Check for unexpected connections to internal services or metadata addresses.
- Rotate cloud credentials and API secrets if unauthorized access is suspected.
Patching is particularly important because updating the software does not automatically invalidate credentials that may already have been exposed.
Protecting ML Infrastructure
Machine learning platforms increasingly sit close to sensitive datasets, cloud credentials, source code, and production workloads. As a result, security weaknesses in these systems can have consequences well beyond the ML platform itself.
The latest activity reinforces the importance of treating MLflow deployments as production infrastructure. Keeping tracking servers off the public internet, enforcing authentication, controlling network egress, and monitoring unusual requests can significantly reduce the risk of exploitation.
Organizations should also review their ML infrastructure regularly for other exposed services, outdated components, and unnecessary network access.
About the Author
