MLflow Under Attack: Critical SSRF Exposes Cloud Credentials and Internal Services

CISA Adds CVE-2026-64849 to the KEV Catalog

CISA has reported active exploitation of CVE-2026-64849, a critical vulnerability in MLflow, an open-source platform used to develop, evaluate, and monitor machine learning models, artificial intelligence applications, and Large Language Models.

The flaw is a Server-Side Request Forgery (SSRF) vulnerability classified as CWE-918. An unauthenticated remote attacker can trick an MLflow server into sending requests to internal resources that are not directly reachable from the Internet.

CVE-2026-64849 was added to the CISA Known Exploited Vulnerabilities (KEV) catalog on August 19, 2026. For U.S. federal civilian agencies, the remediation deadline is September 2, 2026.

The vulnerability has a CVSS 3.1 score of 9.3, with the following vector:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N

The score reflects the lack of required authentication, remote exploitability, and high confidentiality impact. CISA also describes the exploitation as active and automatable, with complete technical impact.

According to available information, attackers began scanning for vulnerable MLflow systems within hours of the CVE assignment. CISA has not disclosed further details about the observed attacks.

Which MLflow Deployments Are Exposed

The risk primarily affects tracking servers started with:

mlflow server

and configured without authentication, using the default SQLite database:

sqlite:///mlflow.db

This configuration is relevant because model registry webhooks require a SQL store. The default server therefore meets the requirements for exposing the affected APIs.

A deployment is particularly exposed when the tracking server:

• is reachable from the Internet;
• does not require authentication;
• can access internal networks or cloud services;
• can communicate with instance metadata endpoints;
• uses model registry webhook functionality.

MLflow records more than 30 million downloads per month and is used by thousands of organizations. The vulnerability may therefore affect development environments, MLOps platforms, and cloud infrastructure hosting AI models or pipelines.

Version information is not fully consistent across the advisories. NVD considers all versions before 3.15.0 vulnerable. The GitHub Security Advisory, however, lists versions up to and including 3.13.0 as affected, while identifying release 3.15.0 and patch #24258 as the fixes.

The exploit was confirmed on MLflow 3.13.0 with the default SQLite database. As a precaution, deployments earlier than 3.15.0 should be treated as vulnerable.

How the SSRF Bypass Works

The primary attack path involves the unauthenticated endpoint:

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

This endpoint tests a webhook and returns the caller the response status received from the remote service, together with its response body.

MLflow performs an initial check on the webhook URL. It validates the scheme, resolves the hostname, and rejects non-public addresses, including private, loopback, link-local, and instance metadata service addresses. Normally, only the https scheme is allowed.

However, the check does not bind the verified IP address to the subsequent connection. The delivery component:

• automatically follows HTTP redirects;
• does not disable allow_redirects;
• does not revalidate the URL in the Location header;
• may perform a new DNS resolution when connecting.

An attacker can therefore register a webhook pointing to a seemingly legitimate public HTTPS host. After passing validation, the attacker-controlled server responds with a 302 redirect to an internal resource, such as:

http://169.254.169.254/latest/meta-data/iam/security-credentials/

The MLflow server follows the redirect and sends the request from its own network environment. The /test endpoint then returns the upstream HTTP status code and response body to the attacker.

The second bypass path uses DNS rebinding. The DNS resolution performed during the initial check may return a public address, while the resolution performed by the HTTP library during the connection may point to an internal address. Because the approved IP is not pinned during validation, the request can reach a different destination.

The vulnerability allows attackers to contact:

• AWS IMDS endpoints and other cloud metadata services;
• internal administrative services;
• loopback addresses;
• ports and hosts on private networks;
• systems not exposed beyond the network perimeter.

Access to cloud metadata can expose temporary AWS IAM credentials, tokens, and other secrets. The SSRF can also be used for port scanning and internal host discovery.

The advisory distinguishes between a “blind” SSRF, associated with the normal event delivery path, and an SSRF that allows response retrieval through the /test endpoint.

The PoC Demonstrates Retrieval of Internal Data

The published demonstration follows three steps.

First, it attempts to register a webhook pointing to a local address such as 127.0.0.1. The check returns an HTTP 400 error because the scheme or address is not allowed.

Next, a webhook is registered against a public HTTPS host controlled by the attacker. The URL passes validation and is accepted.

Finally, the attacker’s server responds with a redirect to an internal service. The attacker then calls the /test endpoint, which may return a structure similar to:

{
  "result": {
    "success": true,
    "response_status": 200,
    "response_body": "<internal service content>"
  }
}

In a local test, the researcher manually inserted values such as the following into the internal service:

INTERNAL_SECRET=mlflow_ssrf_proof_7f3a91
role=admin

These were not real cloud credentials. The test nevertheless demonstrates that the internal response body can be relayed to the attacker.

The attack requires no authentication and is executed by the MLflow server, not by the victim’s browser or computer. Event values must also use uppercase proto names, such as REGISTERED_MODEL and CREATED.

Patches, Mitigations, and Response Activities

The fix is available in MLflow 3.15.0 and is associated with pull request #24258 and the following commit:

ba949522477cbd5915aa55d29b0cfad7d5ddf939

The project introduced SSRFProtectedHTTPAdapter, which checks the remote socket IP address immediately after connection and before the TLS or HTTP exchange. The check is also applied to redirects, preventing the bypass through 302, 307, and 308 responses.

This measure also addresses DNS rebinding: the IP address actually reached is verified instead of relying solely on the initial resolution.

Administrators should:

1. upgrade MLflow to version 3.15.0 or later;
2. prioritize Internet-exposed tracking servers without authentication;
3. enable effective authentication and verify webhook authorization;
4. restrict outbound connections from the MLflow process;
5. block access to 169.254.169.254, private networks, loopback addresses, and unnecessary administrative services;
6. review proxies, firewalls, and egress filtering to prevent requests to internal destinations.

Logs should be analyzed for requests to:

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

Suspicious activity also includes webhook registration pointing to unexpected external hosts, redirects to private addresses, and access to 169.254.169.254.

If an instance may have been exploited, organizations should assess whether cloud credentials, tokens, or secrets were exposed. Potentially compromised AWS IAM credentials must be revoked or rotated, alongside an investigation of subsequent usage.

The vulnerability was privately reported on June 12, 2026, by @freeman-bb. An independent review by @AUTHENSOR was publicly disclosed on June 26, 2026, in issue #24179.

CVE-2026-64849 should not be confused with CVE-2025-14279, which concerns a CSRF vulnerability involving DNS rebinding and is classified as CWE-352, not as this type of server-side SSRF.