Start with Identity
← Blog
News

An MLflow SSRF reaches cloud metadata services, and scanning started within hours

CVE-2026-64849 (CVSS 9.3) abuses MLflow's model-registry webhooks to proxy requests into internal services, including cloud metadata endpoints that hand out credentials. Fixed in 3.15.0; exploitation began the day of assignment.

By SWI Community TeamAug 18, 2026Updated Aug 29, 2026

watchTowr disclosed CVE-2026-64849 (CVSS 9.3), a server-side request forgery in MLflow's model-registry webhooks that lets an attacker proxy requests through the MLflow host into internal services, including cloud instance metadata endpoints. It bypasses an earlier fix by abusing redirect handling. Versions before 3.15.0 are affected. Indiscriminate scanning for exposed MLflow instances began within hours of the CVE being assigned on August 17, 2026, with confirmed exploitation against cloud-hosted deployments. watchTowr and independent researchers reported the flaw, and advise reviewing audit logs and checking credential exposure rather than treating patching as the end of the response.

Why it matters

The instance metadata service is a credential vending machine that authenticates callers by network position alone: anything that can issue an HTTP request from the host gets the role attached to it. That makes every SSRF in a cloud-hosted application an identity vulnerability, not a networking one, and it is why static API key abuse so often begins with a request the application made on an attacker's behalf.

MLflow is a sharper case than most because ML platforms accumulate credentials by design: object storage for artifacts, a database for the tracking store, registry tokens, and whatever the training jobs need. The role attached to that host is usually broad, and nobody scoped it expecting it to be reachable from the internet.

Three controls change the outcome, in order. Require IMDSv2 (or your provider's equivalent session-token-bound metadata) so a plain SSRF cannot read the endpoint. Scope the instance role to the buckets and tables MLflow actually touches, so a stolen token is worth little. Prefer short-lived workload identity over long-lived keys in the environment. Then patch to 3.15.0, take MLflow off the public internet, and rotate anything its role could reach, since the credentials it vended before you patched still work.

Source: The Hacker News

Last reviewed By SWI Community TeamSuggest a correctionHow we research
Independent analysis. No vendor sponsorship.