MLflow SSRF Is Stealing Cloud Credentials — and Today Is the CISA Deadline

• The Mess: Attackers are actively exploiting a critical MLflow SSRF flaw to reach cloud metadata services and steal IAM credentials from exposed AI infrastructure.
• The Damage: One unauthenticated request can turn an MLflow server into a proxy straight into AWS, Azure or Google Cloud internals.
• The Fix: Upgrade MLflow to 3.15.0 or later immediately, then investigate cloud credentials and audit logs for signs of exploitation.

MLflow was supposed to help teams manage machine-learning experiments.

Instead, attackers are using vulnerable MLflow servers as a bridge into cloud environments.

The vulnerability is CVE-2026-64849.

It carries a CVSS score of 9.3.

It is in CISA’s Known Exploited Vulnerabilities catalog.

And today, September 2, 2026, is the CISA remediation deadline for U.S. federal civilian agencies.

This isn’t theoretical exploitation.

Attackers started scanning for exposed MLflow instances within hours of the vulnerability being assigned.

The Bug Is an SSRF Bypass

CVE-2026-64849 is a server-side request forgery vulnerability in MLflow’s webhook delivery functionality.

The vulnerable component attempts to prevent SSRF by checking where a webhook URL resolves.

That sounds reasonable.

It wasn’t enough.

MLflow validated the original destination but didn’t properly lock the connection to the address that had been checked.

The application could then follow a redirect or resolve the hostname again when making the actual connection.

The attacker gets a security filter that says:

“This URL looks safe.”

Then the server connects somewhere else.

That is the core failure.

No Authentication Required

The default MLflow Tracking Server exposes the affected webhook functionality without authentication.

That makes the bug considerably nastier.

An attacker who can reach the vulnerable MLflow server does not need to steal an account first.

They can abuse the webhook API to make the server send requests into networks the attacker cannot directly reach.

The /api/2.0/mlflow/webhooks/{id}/test endpoint is particularly dangerous because it returns the upstream response to the requester.

That turns SSRF into a full-read primitive.

The attacker doesn’t merely make the request.

They can potentially see the response.

The Cloud Metadata Endpoint Is the Prize

Why would an attacker care about an internal HTTP request?

Because cloud infrastructure has a very interesting internal service:

instance metadata.

AWS, Google Cloud and Azure environments can expose temporary credentials and identity information through metadata services.

If the compromised MLflow server can reach those endpoints, the attacker may be able to retrieve credentials associated with the machine.

That’s the jackpot.

The attack chain becomes:

Internet → vulnerable MLflow → SSRF → cloud metadata → credentials

The attacker doesn’t need direct access to the cloud network.

MLflow provides the connection.

Attackers Started Scanning Almost Immediately

WatchTowr reported that its global honeypot infrastructure began seeing attackers scanning for exposed MLflow Tracking Servers within hours of the CVE being assigned on August 17.

The observed activity specifically targeted cloud metadata endpoints and attempted to extract credentials and secrets.

VulnCheck reported similar malicious scanning activity.

This wasn’t a slow research campaign.

The vulnerability became a target almost immediately after disclosure.

That speed matters.

Once a vulnerability can be turned into an automated scanner, defenders don’t get weeks to react.

They get hours.

The Attack Works Through a Redirect

The original SSRF protection checks the hostname.

An attacker can provide a publicly reachable HTTPS server.

That destination passes the validation.

Then the attacker’s server responds with a redirect.

The vulnerable MLflow instance follows it.

The redirected destination can point toward an internal service or cloud metadata endpoint.

The original security check doesn’t protect the second connection.

That’s the hole.

A security mechanism existed.

The attacker simply moved the dangerous destination to the next step.

DNS Rebinding Makes It Worse

There is another path.

The attacker can control DNS resolution.

The first lookup returns a public IP address.

MLflow approves it.

The second lookup returns an internal address.

The request goes somewhere completely different from the address that passed validation.

This is a classic time-of-check/time-of-use problem.

The application checks one thing.

Then later acts on another.

The MLflow maintainers fixed this by moving SSRF protection to the actual network connection rather than trusting the earlier hostname resolution.

The Fix Is Not Another Configuration Flag

The proper fix is upgrading to:

MLflow 3.15.0 or later.

The patched implementation validates the actual peer IP at connection time.

That matters because redirects and DNS changes can create a completely different destination after the original URL validation.

The new protection checks the socket that the application actually connected to.

That’s a much stronger security boundary.

Older MLflow Deployments Are a Problem

MLflow is frequently deployed as infrastructure for machine-learning teams.

That means it can end up sitting on:

• cloud VMs
• Kubernetes clusters
• internal research networks
• CI/CD infrastructure
• shared data-science environments
• public IP addresses

A developer may think:

“It’s just the ML tracking server.”

An attacker sees:

“A machine with cloud credentials.”

That’s a very different interpretation.

The Server May Already Be Compromised

Patching is only half the job.

Because exploitation was observed in the wild, organizations running exposed vulnerable versions should investigate whether attackers already reached their systems.

Check:

• MLflow access logs
• reverse-proxy logs
• cloud audit logs
• AWS CloudTrail
• Google Cloud Audit Logs
• Azure Activity Logs
• unusual metadata-service requests
• unexpected IAM activity
• newly created cloud credentials
• suspicious webhook configurations

Pay particular attention to activity occurring after August 17, 2026, when the CVE became public and exploitation was observed.

Rotate Credentials If There Is Evidence of Access

If a vulnerable MLflow instance could reach cloud metadata, don’t assume the credentials are safe just because nothing obviously malicious happened.

Temporary cloud credentials are valuable because they can provide immediate access to cloud resources.

If logs indicate that metadata credentials may have been exposed:

revoke them.

Then investigate what those credentials could access.

The blast radius depends entirely on the permissions assigned to the workload running MLflow.

An overprivileged MLflow instance could turn a web vulnerability into a much larger cloud compromise.

The AI Infrastructure Problem

This vulnerability is particularly interesting because MLflow sits directly inside the AI development stack.

AI infrastructure is becoming increasingly connected.

A typical environment may contain:

MLflow

→ model registry

→ object storage

→ Kubernetes

→ CI/CD

→ cloud IAM

→ databases

→ secrets

A flaw in one component can therefore become a bridge into several others.

The vulnerable server doesn’t need to contain the valuable data itself.

It only needs network access to something that does.

This Is Why SSRF Keeps Coming Back

SSRF looks simple.

An application fetches a URL.

The attacker controls the URL.

The server makes the request.

But cloud environments turned SSRF into something much more dangerous.

The vulnerable application often has network access that the attacker doesn’t.

And the cloud metadata service may expose credentials that can escape the original machine entirely.

That’s why SSRF vulnerabilities keep appearing in high-value infrastructure.

The server becomes the attacker’s network proxy.

MLflow Already Had SSRF Protection

This is an especially interesting detail.

MLflow had already implemented protection against requests to private IP ranges.

The problem wasn’t simply:

“Nobody thought about SSRF.”

The security control existed.

The implementation was incomplete.

It validated the destination at one stage but didn’t guarantee that the eventual network connection would reach the same destination.

That’s an important lesson for developers.

A security check isn’t useful if the dangerous operation happens after the check against different state.

CISA Put It in KEV

CISA added CVE-2026-64849 to its Known Exploited Vulnerabilities catalog on August 19.

That happened only two days after the CVE was assigned.

The combination is ugly:

CVSS 9.3

unauthenticated

internet reachable

cloud credential theft

active exploitation

CISA KEV

That is about as clear a patching signal as security teams get.

Today Is the Deadline

For U.S. federal civilian executive agencies, the remediation deadline is September 2, 2026.

That’s today.

The deadline isn’t what makes the vulnerability dangerous.

The exploitation does.

But the date is useful because it highlights how quickly CISA moved this vulnerability through the KEV process.

The agency gave defenders less than two weeks from public disclosure to remediation.

Bugstoday Opinion

This is exactly the kind of vulnerability that makes AI infrastructure dangerous.

Not because MLflow itself is some exotic hacker tool.

Because it sits in the middle of valuable systems.

One unauthenticated SSRF turns the server into a network proxy. The proxy reaches cloud metadata. The metadata can hand over credentials. Those credentials can potentially open doors far beyond MLflow.

That’s an entire attack chain from one HTTP request.

Bugstoday verdict: CVE-2026-64849 is not a vulnerability ML teams should put on the “we’ll patch it during the next maintenance window” list. Attackers were already scanning for exposed MLflow servers within hours of disclosure, CISA put it in KEV, and the flaw can expose cloud credentials without authentication. If your MLflow instance is exposed and still running an affected version, you’re not waiting for an attack. You’re waiting for someone to find it.

Today’s Bugs. Tomorrow’s Breaches.

Sources

• MLflow — GitHub Security Advisory GHSA-7gwp-5pfp-969j
• MLflow — Release 3.15.0
• CISA — Known Exploited Vulnerabilities Catalog
• Cloud Security Alliance — MLflow SSRF Actively Exploited for Cloud Credential Theft
• Canadian Centre for Cyber Security — MLflow Security Advisory
• NVD — CVE-2026-64849