MLflow CVE-2026-64849: SSRF Exploited in the Wild

An unauthenticated server-side request forgery (SSRF) vulnerability in MLflow can turn a reachable Tracking Server into a proxy for accessing internal services, including cloud instance metadata endpoints. MLflow CVE-2026-64849 carries a CVSS score of 9.3 and affects MLflow versions before 3.15.0.

The vulnerability stems from weaknesses in SSRF protections around model-registry webhook delivery. An attacker can submit a public HTTPS destination that passes MLflow’s initial validation and then redirect the server toward an internal address.

The consequences are particularly significant in cloud-hosted environments. MLflow’s webhook test functionality can return the response from the targeted service, potentially exposing temporary cloud credentials, instance identity information or other sensitive data accessible to the affected workload.

CISA added CVE-2026-64849 to its Known Exploited Vulnerabilities (KEV) catalog on August 19, 2026, citing evidence of active exploitation.

CVE-2026-64849 at a Glance

How CVE-2026-64849 Bypasses MLflow’s SSRF Protection

The vulnerability is rooted in MLflow’s model-registry webhook functionality.

MLflow had already introduced an SSRF guard designed to prevent webhook requests from reaching private, loopback and link-local IP addresses. Before delivering a webhook, MLflow’s _validate_webhook_url() function resolves the supplied hostname and checks whether the resulting IP address is permitted.

The weakness appears after that initial check.

An attacker can provide a webhook URL hosted on a legitimate public HTTPS endpoint. Because the hostname resolves to a public IP address, it passes MLflow’s validation.

The attacker’s server can then return an HTTP redirect pointing to an otherwise prohibited internal destination.

The resulting request path can look like this:

Attacker-controlled public HTTPS endpoint → HTTP redirect → internal service or cloud metadata endpoint

MLflow’s webhook delivery follows the redirect, but the original protection did not apply equivalent validation to the redirected destination.

The flaw also creates a DNS-rebinding, or time-of-check/time-of-use (TOCTOU), problem. MLflow validated the hostname first but did not pin the subsequent connection to the IP address that had passed that validation.

As a result, the destination approved during validation did not necessarily have to be the destination contacted during delivery.

MLflow 3.15.0 addresses the problem with connection-time SSRF protections. The fix validates the IP address of the connected peer and applies the protection to connections created while following redirects.

Why MLflow’s /test Endpoint Can Expose Cloud Metadata

Not every SSRF vulnerability gives an attacker access to the response from the targeted internal service.

That distinction makes CVE-2026-64849 particularly important.

MLflow exposes a synchronous webhook testing endpoint:

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

The endpoint returns information from the upstream request, including its response status and body.

That can turn the flaw from a blind SSRF primitive into full-read SSRF.

An attacker who successfully redirects MLflow toward an internal service may therefore be able to retrieve information returned by that service.

Cloud instance metadata endpoints are an especially sensitive target. Depending on the cloud provider, configuration and permissions assigned to the workload, metadata services may expose instance information, identity material or temporary credentials.

A vulnerable MLflow server with access to such a metadata endpoint could therefore provide a route for exposing those credentials to a remote attacker.

The downstream impact should still be assessed carefully.

Exposure of a credential does not prove that the credential was subsequently used. It also does not, by itself, establish lateral movement, persistence or data exfiltration.

Those outcomes require supporting evidence from cloud, application, identity or other relevant telemetry.

Is CVE-2026-64849 Being Exploited?

Yes. CISA added CVE-2026-64849 to its Known Exploited Vulnerabilities catalog on August 19, 2026, citing evidence of active exploitation.

That distinction matters for vulnerability prioritization. CVE-2026-64849 is no longer only a vulnerability with a technically viable exploit path; defenders now have evidence that exploitation is occurring.

Organizations should prioritize MLflow Tracking Servers that are reachable from the internet or other untrusted networks.

In the default MLflow Tracking Server configuration described in the advisory, the affected webhook API is exposed without authentication. Network reachability to such a vulnerable deployment is therefore an important exposure condition.

For security teams, this means asset discovery should accompany patching. Knowing that MLflow exists somewhere in the environment is not enough; teams need to determine which vulnerable Tracking Servers are reachable by untrusted users and what internal resources those servers themselves can reach.

How to Mitigate CVE-2026-64849 and Investigate MLflow Exposure

The primary CVE-2026-64849 mitigation is to upgrade affected installations to MLflow 3.15.0 or later.

Organizations should also reduce unnecessary exposure of MLflow Tracking Servers. Deployments that do not need public access should not be reachable directly from untrusted networks. If immediate patching is not possible, place the vulnerable server behind an authentication-enforcing reverse proxy or another authenticated access layer.

This control can reduce unauthenticated access to the affected webhook API, but organizations should use it only as a temporary measure until they upgrade MLflow.

Patching, however, only closes the vulnerability. It does not establish whether an attacker exploited the server before remediation.

Security teams should review available MLflow, reverse-proxy, network and cloud audit logs for suspicious webhook activity and unexpected requests to internal destinations.

Particular attention should be given to connections involving cloud instance metadata services or other internal resources that should not ordinarily receive requests from MLflow.

If evidence indicates that a vulnerable MLflow deployment accessed a metadata endpoint, investigators should determine:

1. What information the affected workload was permitted to retrieve;
2. Which workload identities or temporary credentials were available;
3. How long potentially exposed credentials remained valid;
4. What cloud permissions those credentials carried; and
5. Whether subsequent activity indicates that those credentials were actually used.

Credential rotation or revocation should follow the exposure assessment rather than an assumption that every vulnerable MLflow deployment leaked secrets.

This incident also reinforces the importance of least-privilege workload identities. Short-lived credentials can limit persistence, while tightly scoped permissions can reduce what an attacker could do during the period in which a credential remains valid.

Securing the Endpoints Around MLflow With Hexnode

CVE-2026-64849 must be remediated at the MLflow application layer. Even though Hexnode does not patch the MLflow vulnerability itself, it can support management and policy enforcement on the managed endpoints used around the affected environment.

Hexnode UEM: Strengthening the Administrative Endpoint Layer

Hexnode UEM supports policy management, platform-specific application management, and endpoint compliance capabilities, along with patch and update management for supported Windows and macOS devices.

For example, administrators can use Hexnode UEM’s patch and update management capabilities for Windows and macOS devices, while UEM policies can apply platform-supported configurations and restrictions to managed devices.

Hexnode UEM does not remediate CVE-2026-64849 inside MLflow itself. The MLflow deployment must be upgraded separately to a fixed version.

Its role is instead to support policy-based device management and compliance checks across supported devices, with patch and update management available for Windows and macOS devices.

Featured resource

Hexnode UEM for Patch Management

See how Hexnode UEM centralizes patch visibility and deployment across supported Windows and macOS endpoints.

Download the One-pager

CVE-2026-64849 Shows Why Internal Reachability Matters

The defining problem in CVE-2026-64849 is not simply that MLflow could make an outbound HTTP request.

The application validated one destination, followed the request to another destination and could return the internal response to an unauthenticated caller.

That sequence undermines an important assumption behind network segmentation: that an external attacker cannot directly communicate with services that are only reachable from inside the environment.

SSRF breaks that assumption by turning the vulnerable application into the intermediary.

For MLflow operators, the response should therefore go beyond applying a patch. Security teams should upgrade to MLflow 3.15.0 or later, identify internet-exposed Tracking Servers, restrict unnecessary network access, review webhook and cloud activity, and assess whether potentially exploited systems exposed sensitive workload credentials.

CVE-2026-64849 is also a useful reminder for organizations deploying AI infrastructure at scale: the security boundary around an internal service is only as strong as the applications permitted to communicate with it.