Attackers Exploit MLflow SSRF to Steal Cloud Keys — Patch to 3.15.0 Now

Daniel Reyes Principal Engineer (AI/ML), YuSMP Group · Securing ML infrastructure for US and EU teams

The short answer

What is CVE-2026-64849?

MLflow is the dominant open-source platform for ML experiment tracking, model packaging, and deployment. Teams use it to log runs, compare hyperparameters, and version model artifacts, typically running a tracking server that ML engineers connect to during training. The server exposes a REST API, and part of that API handles webhooks — outbound HTTP calls that fire when experiments or model versions change state.

CVE-2026-64849 lives in the endpoint that tests those webhooks: POST /api/2.0/mlflow/webhooks/{id}/test. The flaw is a time-of-check-to-time-of-use (TOCTOU) issue. When a webhook is registered, the server validates the target URL. But when the test endpoint fires, the HTTP client follows redirects without re-validating the final destination. An attacker can register a webhook pointing to a URL that initially looks benign but immediately issues an HTTP 302 redirect to an internal address — such as the AWS instance-metadata service at 169.254.169.254 — and the tracking server dutifully fetches and returns the response.

The endpoint requires no authentication, which means any network-reachable attacker can trigger it without credentials. The flaw carries a CVSS 3.1 score of 9.3 and was assigned the GitHub security advisory identifier GHSA-7gwp-5pfp-969j on August 17, 2026. All MLflow versions prior to 3.15.0 are affected.

How does the attack work?

The attack is straightforward enough that automated scanners had already begun probing exposed MLflow instances within hours of the CVE assignment, according to watchTowr’s Attacker Eye honeypot network. The basic chain:

1. Attacker registers a webhook on the MLflow tracking server with a URL pointing to an attacker-controlled redirect server. The initial URL passes validation because it resolves to an external IP.
2. Attacker calls POST /api/2.0/mlflow/webhooks/{id}/test — no authentication required.
3. MLflow’s HTTP client follows the redirect to http://169.254.169.254/latest/meta-data/iam/security-credentials/ (on AWS) or equivalent metadata endpoints on GCP and Azure.
4. The metadata service returns temporary IAM credentials: access key ID, secret access key, and session token.
5. MLflow returns the response to the attacker. Credentials are in hand.

DNS rebinding is a secondary attack path: a domain resolves to a valid external IP for the validation check, then resolves to an internal IP on the actual request. Researchers at Hadrian published a working proof-of-concept covering both paths shortly after the CVE was disclosed.

Why are MLflow servers high-value targets?

Development tooling rarely gets the same hardening attention as production services, yet it often holds production-grade credentials. MLflow tracking servers are a particularly attractive target because:

• IAM roles with broad storage access. MLflow needs to read and write model artifacts and datasets to object storage, so the attached role typically has S3, GCS, or Azure Blob read/write permissions — sometimes on buckets containing training data with customer records.
• Infrequent patching cycles. ML infrastructure is often treated as a shared dev tool maintained by a data engineering team, not a product team with a security SLA. Version upgrades lag.
• Internet exposure by convenience. Teams expose the tracking server so remote ML engineers can log runs from their workstations or from cloud training jobs, often without putting it behind a VPN or authentication proxy.
• Temporary credentials, but with days-long validity. AWS, GCP, and Azure instance-metadata credentials rotate periodically, but the window is long enough for attackers to exfiltrate data or pivot before the key expires.

What it means for US & EU software teams

Any team that ships products with an AI or ML component — recommendation engines, fraud detection, document processing, forecasting — has likely stood up an MLflow tracking server at some point in the development lifecycle. The question is whether that server is still running and still internet-reachable.

For US teams, the immediate concern is the IAM credentials themselves. A stolen temporary credential with S3 access can read training datasets, exfiltrate models, or be used to move laterally into other AWS services. If the role also had permissions to write to infrastructure state files (Terraform backends, for example), the blast radius extends further. Teams building AI/ML data pipelines should audit every tracking server instance against this CVE before the end of the week.

For EU teams, the GDPR angle matters: training data stored in the same cloud storage bucket that MLflow’s role can access may contain personal data. An SSRF-driven credential theft that reaches that data is a reportable breach under Article 33 GDPR — 72-hour notification to the supervisory authority from the moment you become aware. If your MLflow server was exposed, start that clock now, investigate thoroughly, and do not assume no data was accessed just because you see no obvious exfiltration.

Beyond the immediate patch, this vulnerability is a reminder that dev tooling in ML pipelines deserves the same zero-trust network posture as production services. MLflow tracking servers, Jupyter notebooks, Airflow instances, and similar tools should not be internet-reachable without a VPN or strong authentication layer in front of them.

What to do this week

1. Identify all MLflow instances. Check cloud environments, developer workstations, CI/CD runners, and dedicated ML training infrastructure. Look for anything running the tracking server on port 5000 (default) or any other exposed port.
2. Upgrade to MLflow 3.15.0 immediately. This is the only full fix. If you cannot upgrade right now, block port access to the tracking server at the network layer and disable inbound requests to /api/2.0/mlflow/webhooks at the load balancer or WAF.
3. Rotate cloud credentials. Identify the IAM role or service account attached to each MLflow instance. Rotate the temporary credentials and, if the instance used long-lived keys, rotate those immediately. Check all other services that share the same role.
4. Audit cloud logs. Review CloudTrail (AWS), Cloud Audit Logs (GCP), or Azure Activity Logs for unexpected API calls originating from the MLflow server’s IAM role in the 48 hours before patching. Pay attention to GetObject calls on training-data buckets and any AssumeRole calls indicating lateral movement.
5. Enforce network isolation going forward. MLflow tracking servers should sit in a private subnet, behind a VPN or authentication proxy. If remote ML engineers need access, wire it through a bastion or a zero-trust access tool — not a public IP.
6. Enable IMDSv2 (AWS-specific). IMDSv2 requires a PUT request to obtain a session token before metadata can be read, which breaks the SSRF chain for redirect-based attacks. Enforce IMDSv2 via instance metadata options and verify via aws ec2 describe-instances.

Frequently asked questions