MLflow CVE-2026-64849: your ML server hands out cloud keys

There is a CVSS 9.3 hole in MLflow that lets an unauthenticated stranger read your cloud metadata endpoint and walk off with the credentials behind it. Attackers started scanning for it within hours of the CVE being assigned. CISA put CVE-2026-64849 in the Known Exploited Vulnerabilities catalog on August 19. If you stood up an MLflow tracking server during an AI experiment last year and never thought about it again, that server is the story.

What actually happened

MLflow's tracking server exposes a model-registry webhook test endpoint — POST /api/2.0/mlflow/webhooks/{id}/test — with no authentication in the default configuration. It validates the webhook's URL before firing. It does not re-validate the address after following an HTTP redirect. So you point a webhook at a host you control, return a 302 to 169.254.169.254, and MLflow fetches the cloud metadata service for you and hands back the response body.

That is a credential vending machine. watchTowr reported that its honeypot network saw exploitation attempts against cloud-hosted MLflow instances within hours of the CVE assignment on August 17, aimed at reaching metadata services and exfiltrating cloud credentials and secrets. SecurityWeek's coverage tracks the same pattern.

Every version before MLflow 3.15.0 is affected. 3.15.0 is the fix. CISA added it to KEV on August 19, with a September 2 remediation deadline for federal civilian agencies. You do not have that deadline. You have a shorter one, because nobody is scanning federal agencies harder than they are scanning the open internet.

Why an exposed MLflow server matters for your business

The uncomfortable part is not the bug. It is who runs MLflow and how. MLflow is the thing a developer installs in an afternoon to track experiments. It gets deployed to a small VM or an ECS task, it gets a public IP because that was easier than a VPN, and it inherits the instance role — which, on a machine that was only ever going to log metrics, is usually broader than it needs to be.

An SSRF that reads instance metadata converts that instance role into the attacker's role. Whatever the box can do, they can do. S3 buckets, parameter store, whatever else got attached.

Three things, in order:

Find it. Search your cloud accounts for anything listening on port 5000, plus any container image with mlflow in the name. Include the machine somebody set up and stopped using — that one is worse, because nobody is watching its logs.

Patch or unplug. Upgrade to 3.15.0. If you cannot patch today, take it off the public internet entirely; MLflow has no business having a public IP.

Assume the keys moved. If an exposed instance existed before today, rotate the credentials that instance could reach and pull CloudTrail for metadata-service calls and unfamiliar API activity. Requiring IMDSv2 blocks the naive version of this attack and should be the default on every instance you run, patched or not.

Sources: The Hacker News, SecurityWeek, CISA.