MLflow's webhook tester is now a credential-theft tool, and it is on CISA's KEV list

An unauthenticated server-side request forgery flaw in MLflow's webhook creation and testing features, tracked as CVE-2026-64849, is being used to read cloud metadata and steal temporary IAM credentials, and it has been added to CISA's Known Exploited Vulnerabilities list ^[1][3]. That combination moves the problem out of the security backlog and onto the platform team that owns the tracking server, because the advisory summary describes the vulnerable path as reachable on tracking servers in default configurations without authentication ^[4].

The mechanics are unremarkable, which is the point. According to the advisory summary published on dev.to and credited to the MLflow security advisory and CISA, the attacker finds an externally exposed MLflow Tracking Server, uses the unauthenticated API to create a webhook pointing at a public HTTPS server they control, and that server answers with a 302 redirect to a cloud metadata or internal URL ^[5]. MLflow validates only the original URL and follows the redirect target without re-evaluating it, and the webhook test response returns the internal response body, which is where IAM role credentials leave the building ^[5][6]. The same summary notes 307 and 308 redirects preserve the POST method, which turns the flaw into blind writes against internal services ^[7], and that a DNS-based variant works by switching responses for the same hostname from public to internal IPs, exploiting the gap between validation time and connection time ^[8]. From there the described reach extends to internal port scanning, configuration changes, and internal API operations ^[9].

Affected versions are MLflow 3.14.0 and earlier; the fix is 3.15.0 or later ^[10]. The gap between those two is one minor release, so there is no long backport archaeology to do before patching ^[15]. The preconditions listed are equally short: the webhook API is reachable without authentication, the MLflow host can talk to internal services and the metadata endpoint, and the cloud role attached to the instance has real permissions, which is what determines how bad the aftermath is ^[11]. No user action is required, and public MLflow servers are targeted directly; the advisory summary explicitly states email is not an attack vector, which rules out the phishing-awareness reflex ^[12]. Named technologies are the MLflow Tracking Server and the AWS EC2 Instance Metadata Service ^[13]. No threat actor or malware family has been identified ^[14].

Mitigations beyond the upgrade are the ones you would expect and should have already: make MLflow private and put it behind an authenticated reverse proxy, apply metadata service protections, cut the instance role down to least privilege, add egress controls, and validate webhook destination IPs after connection and at every redirect rather than only at submission ^[16].

Detection is network work, not endpoint work. The summary flags connections from MLflow to 169.254.169.254 or RFC1918 addresses immediately after an outbound connection to an attacker-controlled public host, DNS responses for one hostname flipping from public to internal IPs in a short window, and HTTP connections from the MLflow process to link-local, loopback, RFC1918, and internal management ports; it notes network telemetry matters because this usually happens without additional processes spawning ^[17]. On the cloud side, look for API use from new IPs and User-Agents with temporary credentials, and abnormal role enumeration, secret retrieval, or resource operations in CloudTrail, plus IMDS access logs and host flows ^[18].

Worth separating scan noise from a real incident before escalating: the summary's own ladder runs from suspicious requests against the webhook API with no confirmed internal connection, through webhooks created and tested and the server connecting out, to metadata or IAM credential responses returned or cloud API use with stolen credentials, and finally secret retrieval, lateral movement, or resource modification with the stolen role ^[19]. If your logs only reach rung two, you still have to rotate.