CISA recently added a critical vulnerability in MLflow to its Known Exploited Vulnerabilities catalog. This flaw allows server-side request forgery (SSRF) attacks, enabling attackers to access internal services and steal cloud credentials. Federal agencies have two weeks to patch. If you're running MLflow in production, you need to understand why this was exploitable and what controls should've prevented it.
What Happened
Attackers exploited a vulnerability in MLflow, an open-source platform for managing machine learning workflows, to perform SSRF attacks. This vulnerability lets an attacker force the MLflow server to make unauthorized requests to internal services. In cloud environments, this means reaching the instance metadata service and extracting IAM credentials.
Security researchers at watchTowr documented active exploitation. Once attackers have those credentials, they can move through your AWS environment, accessing S3 buckets, databases, and compute resources that the compromised instance can reach.
Timeline
The exact timeline of exploitation isn't public, but CISA's addition to the KEV catalog indicates active attacks. The two-week remediation deadline highlights the threat's seriousness.
For most organizations running MLflow:
- The vulnerability existed in deployed instances before public disclosure.
- Attackers likely scanned for exposed MLflow servers immediately after disclosure.
- Cloud credential theft could've happened within hours of successful exploitation.
- Lateral movement and data exfiltration would follow based on IAM permissions.
If you haven't patched yet, assume reconnaissance has already happened.
Which Controls Failed
This incident reveals failures across multiple security layers:
Network segmentation failed. Your ML platform shouldn't have direct access to cloud metadata services. If MLflow can reach the instance metadata endpoint at 169.254.169.254, you've given it more network access than it needs.
Input validation failed. SSRF vulnerabilities exist because applications trust user-supplied URLs without validating the destination. MLflow accepted requests that should've been rejected at the application layer.
Least privilege failed. The IAM role attached to your MLflow instance determines the blast radius. If that role has broad permissions across your AWS environment, a credential theft becomes an infrastructure compromise.
Vulnerability management failed. If you're patching MLflow more than two weeks after CISA's KEV addition, you're not meeting the remediation timeline that federal agencies must follow. Your patch cycle is too slow for critical infrastructure components.
Monitoring failed. SSRF attacks generate unusual outbound requests. If your MLflow instance started making requests to 169.254.169.254 and you didn't get an alert, you're not monitoring application behavior effectively.
What Standards Require
NIST 800-53 Rev 5 addresses these failures directly:
SC-7 (Boundary Protection) requires you to monitor and control communications at external and key internal boundaries. Your ML platform sits at an internal boundary between application logic and cloud infrastructure. You need explicit rules about what it can reach.
CM-7 (Least Functionality) prohibits functions, ports, protocols, and services that aren't required. If MLflow doesn't need to query the instance metadata service, block that traffic at the network level.
AC-6 (Least Privilege) requires each component to operate with minimum necessary privileges. Review the IAM role attached to your MLflow instances. Does it need S3 write access across all buckets? Probably not.
SI-10 (Information Input Validation) mandates that applications check the validity of information inputs. SSRF happens when you skip this check for URLs.
For PCI DSS environments, Requirement 6.4.3 specifically addresses script behavior: "Validate all input to mitigate common vulnerabilities." If your ML platform processes payment data or connects to systems that do, SSRF vulnerabilities violate this requirement.
ISO 27001 Control 8.25 (Secure Development Lifecycle) requires security considerations in all development phases. If you're deploying open-source ML platforms without reviewing their security posture, you're not meeting this control.
Lessons and Action Items
Patch immediately. If you're running MLflow, update to the patched version. Don't wait for your next maintenance window. CISA gave federal agencies two weeks; you should move faster.
Implement network controls. Add firewall rules that prevent your MLflow instances from reaching 169.254.169.254. This blocks the most common SSRF target in AWS. For GCP, block 169.254.169.254 and metadata.google.internal. For Azure, block 169.254.169.254/latest/meta-data.
Review IAM permissions. The role attached to your MLflow instance should only access resources it needs for ML operations. If it has admin permissions or broad S3 access, create a new role with explicit resource ARNs.
Add monitoring rules. Alert on outbound requests to metadata endpoints. Alert on IAM credential usage from unexpected IP addresses. Alert on S3 API calls that don't match normal ML workflow patterns.
Inventory your AI infrastructure. You can't patch what you don't know about. Document every ML platform, model serving endpoint, and Jupyter notebook environment. Include network location, IAM roles, and data access patterns.
Test your detection. Simulate an SSRF attack against a test MLflow instance. Does your SIEM catch it? Do you get an alert? Can you trace the attack through your logs? If not, your detection needs work.
Update your patch SLA. If critical vulnerabilities in production systems take longer than 72 hours to patch, you're creating windows for exploitation. CISA's two-week mandate is the floor, not the ceiling.
The MLflow vulnerability isn't unique. Every platform you deploy has potential vulnerabilities. The question isn't whether flaws exist but whether your controls limit the damage when they're exploited. Network segmentation, least privilege, and input validation would've reduced this from infrastructure compromise to a failed attack attempt.
Review your ML infrastructure this week. Don't wait for the next KEV addition.
