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.
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
Related on Start with Identity
- BlogGhostSplice splits a malicious instruction across MCP tool calls, and refusal rates go to zero
ASSET Research Group fragmented an exfiltration request across MCP channels so no single piece looked malicious. Models that refused the intact instruction 100
- BlogNearly one in ten exposed LiteLLM gateways still accept the documentation's example admin key
Wiz found 3,074 internet-facing LiteLLM gateways, of which 294 accepted sk-1234, the key printed in the setup docs. In 191 of those no key was set at all, which
- BlogOne actor signed in as Entra ID apps with stolen secrets and reached 27 organizations, Todyl says
Todyl is tracking an ongoing campaign in which one operator uses stolen client secrets to sign in to Microsoft Entra ID as app registrations, reaching 27 organi
- CVECommvault Web Server zero-day that exposed Metallic Microsoft 365 app secrets
An authenticated webshell flaw in Commvault Web Server, used as a zero-day in Commvault's Azure environment, where the actor may have reached client secrets cus
- ReportIdentity Breach Report 2026: how attackers get in
123 identity breaches, 2021 to 2026: MFA was bypassed in 25 of the 41 with a known MFA status, and 44% of 2025-2026 cases had no login for MFA to protect.
- CVELiteLLM MCP gateway accepts any Bearer token after key validation fails
LiteLLM's MCP Streamable HTTP endpoint fell back to an empty auth object when key validation failed, so a fabricated Authorization header reached the gateway's