CISA flags exploited MLflow SSRF flaw in AI tracking servers

CISA added CVE-2026-64849, an MLflow server-side request forgery flaw, to its Known Exploited Vulnerabilities catalog on August 19 after evidence of active exploitation. The warning matters because MLflow is widely used to track machine learning experiments, models, and agent workflows, and many teams run tracking servers close to sensitive cloud resources.

The GitHub advisory for the MLflow project describes the issue as a critical unauthenticated SSRF in webhook delivery. In affected default deployments, a reachable MLflow Tracking Server can be made to call a webhook test endpoint that follows redirects after only validating the original URL. That means an attacker can send the server toward internal addresses or cloud metadata services and, in the test path, receive the upstream response body back.

The advisory lists a CVSS 3.1 score of 9.3 and identifies the weakness as CWE-918. It says the flaw affects MLflow versions at least through 3.13.0 and was fixed by a patch that adds connection-time SSRF protection, validating the peer IP after a socket connects so redirect targets and DNS rebinding attempts are covered. MLflow 3.15.0 is the practical update target cited by vulnerability databases and release references tied to the fix.

What teams should check next

• Inventory internet-reachable MLflow Tracking Servers, especially systems used by data science, MLOps, and AI platform teams.
• Upgrade MLflow to 3.15.0 or later where the project fix is available.
• Restrict tracking-server access behind authentication, VPN, private networking, or trusted identity-aware proxies.
• Review logs for unexpected webhook creation, webhook test calls, redirects to internal IP ranges, and suspicious requests to cloud metadata endpoints.
• Rotate cloud credentials if exposed MLflow servers had access paths to instance metadata or internal secret services.

The social hook is simple: an AI platform server does not need to run attacker code to leak secrets if it can be tricked into fetching the wrong internal URL. One likely effect is that security teams will treat exposed MLOps dashboards more like production application infrastructure, not as low-risk lab tooling. That is a useful shift for future AI security coverage because the risk sits at the boundary between model operations, cloud identity, and ordinary web application hardening.

It remains unclear how widespread successful exploitation is outside the evidence CISA relied on for KEV inclusion. But the decision rule is clear: if MLflow is reachable from untrusted networks, patching and access control should outrank routine backlog triage.

Sources

• www.cisa.gov
• github.com
• github.com

Cover photo by cottonbro studio on Pexels, used under the Pexels License.