MLflow Under Active Attack: CISA Adds Critical SSRF Flaw to Exploited Catalog

Category: CISA Advisories

Let me ask you something: if you locked your front door but left a side window open, would you still consider your business secure?

That is essentially what happened with a serious MLflow vulnerability. A security check was added to block dangerous destinations, but attackers found a way around it by using redirects and DNS tricks. Now, they are using exposed MLflow servers as a pathway into internal services and cloud environments.

CISA added CVE-2026-64849 to its Known Exploited Vulnerabilities catalog on August 19, 2026. The listed action due date is September 2, 2026.

If your business runs MLflow, especially in the cloud, this is not a vulnerability to place in the normal patch queue.

Why MLflow matters to your business

MLflow is a popular open-source AI and machine-learning platform used to track experiments, manage models, and support AI development workflows.

The project has more than 27,000 GitHub stars and more than 60 million monthly downloads. That popularity makes it useful to businesses: and attractive to attackers.

MLflow is often deployed as a Tracking Server, which acts like a central office for machine-learning projects. It may store experiment data, model information, credentials, configuration details, and connections to cloud resources.

Here’s the problem: a default MLflow Tracking Server can expose the model-registry webhooks API without authentication.

And that creates a dangerous opening.

What is CVE-2026-64849?

CVE-2026-64849 is an unauthenticated server-side request forgery, or SSRF (pronounced “S-S-R-F”). SSRF allows an attacker to trick a server into making requests on the attacker’s behalf.

Think of it this way.

You cannot enter the locked office next door, but you convince your receptionist to walk inside and bring you whatever is on the desk. The receptionist is trusted by the building. You are not.

In this case, MLflow can be manipulated into reaching internal services that should never be available to an outside visitor.

The vulnerability affects MLflow versions before 3.15.0 and carries a CVSS score of 9.3, which is considered critical. It is classified as CWE-918, the standard weakness category for SSRF vulnerabilities.

The vulnerable request involves the webhook test endpoint:

POST /api/2.0/mlflow/webhooks/{id}/test

On an unprotected Tracking Server, an attacker may be able to call this endpoint without logging in.

How attackers bypassed MLflow’s protection

MLflow added SSRF protection in version 3.10.0. That protection checked the original webhook URL and attempted to prevent connections to private, loopback, link-local, and other restricted IP addresses.

That sounds helpful, right?

It was: but the check did not remain attached to the actual connection.

The vulnerable process worked roughly like this:

MLflow checked the original webhook hostname.
The hostname resolved to a public IP address, so it passed validation.
MLflow followed an HTTP redirect.
The redirected request was resolved again without properly validating the new destination.

An attacker could host a public URL that looked harmless. When MLflow contacted it, the attacker’s server could respond with a redirect to an internal destination.

That destination could be:

A localhost service such as 127.0.0.1
An internal business application
A private network service
A cloud metadata endpoint such as 169.254.169.254

And here’s where it gets scary: the vulnerable webhook test endpoint can return both the upstream response status and response body.

That makes this a full-read SSRF, not merely a blind request. The attacker may be able to read the response from the internal system.

Isometric cloud infrastructure showing an unsafe redirected network path toward a metadata service

Why cloud-hosted MLflow servers face serious risk

Cloud platforms often provide metadata services that applications use to obtain temporary credentials and configuration information.

The link-local address 169.254.169.254 is commonly associated with these services. If an attacker can force an exposed MLflow server to contact that address and return the response, cloud credentials may be exposed.

That could include:

Temporary access keys
Instance or workload credentials
Cloud account details
Deployment configuration
Environment variables and secrets
Information about other internal systems

The exact impact depends on your cloud provider, permissions, network design, and the credentials available to the MLflow host.

But you should not assume the risk is limited to MLflow itself. A stolen cloud credential can become a key that opens additional doors.

Attackers moved quickly

WatchTowr reported observing exploitation attempts against internet-exposed MLflow instances within hours of the CVE being assigned.

Its telemetry showed attackers scanning for cloud-hosted MLflow systems and attempting to use the SSRF flaw to access metadata services and retrieve credentials.

That speed matters.

You may think, “We will patch it during our next maintenance window.” An attacker may think, “We found it this morning. Let’s test it now.”

CISA’s KEV listing confirms that this is an actively exploited vulnerability. The NVD entry also records the critical 9.3 rating and identifies all versions before 3.15.0 as affected.

The September 2 deadline applies to covered federal agencies, but your business does not need to wait for a government deadline to act.

The fix is MLflow 3.15.0

The primary remediation is straightforward:

Upgrade MLflow to version 3.15.0 or later immediately.

The fix was introduced through MLflow pull request #24258, which added connection-time IP validation to webhook delivery.

MLflow’s new protection checks the actual peer IP address of the connected socket immediately after the connection is established and before TLS or HTTP data is exchanged.

That distinction is important.

Instead of trusting an earlier hostname lookup, the server checks where the connection actually landed. The protection also applies to new connections created during redirects, closing the original validation gap and helping prevent DNS rebinding.

You can review the vendor’s GHSA-7gwp-5pfp-969j advisory and the MLflow 3.15.0 release for additional technical details.

What you should do now

Start by identifying every MLflow deployment your business owns or operates.

Then take these steps:

Check the installed MLflow version.
Upgrade all affected instances to 3.15.0 or later.
Prioritize internet-exposed Tracking Servers.
Restrict access to the webhook API.
Place MLflow behind authentication and a VPN or trusted network boundary.
Keep MLflow off the public internet whenever possible.
Disable or remove webhooks you do not need.
Review outbound firewall and egress rules.
Block unnecessary access to cloud metadata and private network ranges.

These controls reduce your exposure, but they are not a substitute for upgrading. The underlying flaw exists in the vulnerable code, so configuration changes alone may not fully resolve the problem.

IT consultant reviewing cloud access controls and isolating a network connection

Treat an exposed older server as a potential security incident

If an affected MLflow server was reachable from the internet, do not stop after installing the update.

Review your logs for:

Requests to /api/2.0/mlflow/webhooks/
Repeated webhook test activity
Requests from unfamiliar IP addresses
Redirects to unusual external domains
Connections to 169.254.169.254
Connections to localhost or private internal addresses
Unexpected access to cloud services or internal applications

Also ask an important question: Could sensitive credentials have been exposed?

If the answer is possible: or if your logs show suspicious activity: rotate cloud credentials and other secrets that may have been accessible from the MLflow host.

That may include:

Cloud access keys
Instance-role credentials
API tokens
Database passwords
Service-account credentials
Secrets stored in environment variables or configuration files

Coordinate the review with your cloud provider, application owners, and incident-response team. Preserve relevant logs before rotating credentials if you need to investigate the attack path.

Cybersecurity response team securing cloud credentials while reviewing audit records

The bigger lesson for small businesses

MLflow is an AI platform, but the security lesson applies to every internet-facing application.

A server does not need to store your most important files to become dangerous. If it can reach your internal network or cloud services, attackers may try to use it as a bridge.

That is why proactive security matters. You need to know what is exposed, what can communicate outbound, which services lack authentication, and where credentials are stored.

Platinum Web Services helps St. Louis small businesses with vulnerability response, network security, cloud protection, and ongoing IT support. We can help you identify exposed systems, prioritize urgent patches, review suspicious activity, and build a safer technology environment.

For assistance, contact Platinum Web Services. Business hours are 24/7.