As reported by BleepingComputer, CISA has added CVE-2026-64849 — a critical DNS-rebinding SSRF bypass in MLflow's webhook delivery mechanism — to its Known Exploited Vulnerabilities catalog, confirming active exploitation in the wild. This is a watershed moment for AI infrastructure security: the tooling layer that teams use to build, evaluate, and deploy LLMs is now being treated by attackers as a first-class entry point into cloud environments.
Vulnerability at a Glance
| Field | Detail |
|---|---|
| CVE | CVE-2026-64849 |
| Severity | Critical (CVSS score not disclosed in advisory; rated Critical by MLflow team) |
| Root Cause | DNS-rebinding SSRF bypass in MLflow outbound webhook delivery |
| Affected Component | MLflow Tracking Server — unauthenticated /api/2.0/mlflow/webhooks/{id}/test endpoint |
| Affected Versions | MLflow versions prior to 3.15.0 |
| Patched Version | MLflow 3.15.0 |
| Authentication Required | No — exploitable unauthenticated on default deployments |
| Active Exploitation | Yes — confirmed by CISA KEV catalog addition (August 20, 2026) |
| Vendor Advisory | MLflow security advisory (issued ~July 30, 2026) |
Why This Matters More Than a Typical SSRF
SSRF flaws are common, but this one is particularly dangerous because of the default deployment posture. The standard mlflow server command with the SQLite backend and no authentication — the configuration most data science teams use for quick prototyping — exposes the webhook test endpoint to anyone who can reach the server. That endpoint not only sends arbitrary HTTP requests but returns the upstream response body to the caller. This turns the MLflow server into a proxy that can reach AWS Instance Metadata Service (IMDS), internal admin panels, and any service within the network boundary.
The attack chain is trivially automatable: enumerate the webhook API, craft a DNS-rebinding payload that resolves to 169.254.169.254 after the initial SSRF validation check, and exfiltrate IAM role credentials — all without a single login or credential. In cloud environments where MLflow runs on EC2 with an attached IAM role, this is a one-step path to cloud account compromise.
Who Is Most at Risk
- Data science and ML engineering teams running MLflow Tracking Servers exposed to the internet or on shared internal networks without authentication — the default configuration.
- Cloud-hosted AI workloads on AWS EC2, GCP Compute Engine, or Azure VMs where MLflow runs with instance-level IAM permissions. IMDSv1 environments are especially vulnerable since IMDSv2 requires token-based requests that add a partial mitigation.
- Organizations with permissive network segmentation where a compromised MLflow instance can reach databases, Kubernetes API servers, internal dashboards, or other metadata services.
- Any deployment that has not upgraded to MLflow 3.15.0 or applied network-level mitigations.
The broader signal here is clear: AI/ML infrastructure tooling — model registries, experiment trackers, feature stores, inference servers — is now a priority target. These systems often run with elevated cloud permissions, are managed by teams outside traditional security oversight, and default to insecure configurations optimized for developer velocity.
Shield53 Recommendations
Immediate Actions
HttpTokens=required at the instance metadata level.Detection Guidance
- Monitor MLflow server logs for requests to
/api/2.0/mlflow/webhooks/*/testwith unusual destination URLs, especially those targeting169.254.169.254,localhost,0.0.0.0, or internal RFC1918 ranges. - Watch for DNS queries from MLflow hosts that resolve external domains to loopback or link-local addresses — a hallmark of DNS-rebinding attacks.
- Alert on any IAM credential retrieval from IMDS originating from MLflow process workloads, especially outside expected deployment windows.
- Review cloud audit logs (CloudTrail, GCP Audit Logs) for API calls using credentials that may have been exfiltrated through this vector.
Strategic Implications
Security teams should treat AI/ML infrastructure as a new attack surface category requiring the same controls applied to traditional application infrastructure: authentication, network segmentation, vulnerability management, and runtime monitoring. The rapid adoption of open-source AI tooling has outpaced the security maturity of most organizations. Conduct a full audit of your AI stack — not just MLflow, but also tools like Kubeflow, Airflow, JupyterHub, model serving frameworks, and vector databases — for similar exposure patterns. The pattern of unauthenticated APIs with cloud metadata access is systemic across this ecosystem.
Federal agencies have until approximately September 3, 2026 (two weeks from KEV addition per BOD 26-04) to remediate. Private sector organizations should treat this with equal urgency given confirmed active exploitation.
