MLflow SSRF Flaw Actively Exploited for Credential Theft

Key Takeaways

CVE-2026-64849 is a critical (CVSS 3.1 base score 9.3) server-side request forgery vulnerability in MLflow, the widely deployed open-source platform for managing the machine learning lifecycle, affecting every release prior to version 3.15.0 [1][2]. The flaw lives in MLflow’s webhook delivery mechanism: the _validate_webhook_url() function checks that a webhook’s destination resolves to a public IP address when the webhook is registered, but the delivery code that actually performs the HTTP request follows redirects and re-resolves hostnames without pinning the previously validated address, a classic time-of-check-to-time-of-use gap that also leaves the server exposed to DNS rebinding [2][3]. An attacker who registers a webhook pointing at a public HTTPS endpoint they control can have that endpoint respond with an HTTP redirect to an internal address, such as a cloud provider’s instance metadata service at 169.254.169.254, and the unauthenticated POST /api/2.0/mlflow/webhooks/{id}/test endpoint will reflect the resulting response body back to the caller [2][3][4]. Security firm watchTowr reported that its Attacker Eye honeypot network observed adversaries scanning for and targeting cloud-hosted MLflow instances within hours of the CVE’s public assignment on August 17, 2026, specifically attempting to extract cloud credentials and secrets [1][5]. As of this writing, CVE-2026-64849 does not appear to be confirmed on CISA’s published Known Exploited Vulnerabilities catalog, though CISA’s own vulnerability-tracking data records a coordinator decision on the CVE dated August 19, 2026 with an SSVC exploitation status of active, and multiple security firms have independently documented exploitation regardless of formal catalog status [1][5][6]. Organizations running MLflow anywhere in their model development, experiment tracking, or model registry pipeline should upgrade to 3.15.0 or later immediately and treat any exposed instance as a potential credential-exposure incident rather than a routine patch [2][7].

Background

MLflow began as a Databricks project in 2018 and joined the Linux Foundation in 2020 as a vendor-neutral home for what its creators describe as an end-to-end open-source platform for managing the machine learning lifecycle, covering experiment tracking, reproducible packaging of training code, and model registry and deployment [8]. That last capability, the model registry, is the part of MLflow implicated in this vulnerability: it lets teams register trained models, promote them through staging and production, and configure webhooks that notify external systems, such as CI/CD pipelines or Slack channels, whenever a model’s registration state changes. Because MLflow is frequently deployed as a shared internal service reachable by data science teams, automation pipelines, and sometimes external collaborators, its tracking server is commonly run without authentication enabled, an operational pattern that MLflow’s project documentation appears to treat as an accepted trust assumption rather than a defect requiring a default fix, based on a reading of the project’s public security guidance and its unauthenticated-by-default configuration.

That assumption has proven costly before. Aggregated vulnerability tracking lists more than thirty published CVEs against MLflow since 2022, spanning path traversal flaws in model-version and artifact-location handling and deserialization vulnerabilities in model-loading code for frameworks such as PyTorch, scikit-learn, and LightGBM [9], including a critical path-traversal flaw in the framework’s archive-extraction logic disclosed in 2025 [10]. CVE-2026-64849 continues that pattern but adds a new dimension: rather than compromising the MLflow server itself, it uses the server as a proxy to reach services the attacker could not otherwise contact directly, most notably the cloud metadata endpoints that issue temporary credentials to the compute instance running MLflow. Notably, MLflow’s maintainers had already recognized SSRF as a risk in this component; outbound destination validation for webhooks was added in version 3.10.0 specifically to block requests to non-public IP ranges [4]. CVE-2026-64849 is, in effect, a bypass of that existing defense rather than an entirely novel weakness, which is a pattern worth flagging on its own: a security control that validates a destination once, at registration time, cannot be assumed to hold once the request is actually delivered.

Security Analysis

The technical mechanism is narrow and specific to how MLflow validates and then delivers webhook requests. When a user registers a webhook, or when the unauthenticated POST /api/2.0/mlflow/webhooks/{id}/test endpoint is called to test one, _validate_webhook_url() resolves the target hostname and confirms it maps to a publicly routable address, rejecting obviously internal targets like 127.0.0.1 or 169.254.169.254 outright [2][3]. The flaw is that this check happens only once, against the original URL, while the separate delivery logic in MLflow’s webhook module performs the actual HTTP request using a client that follows redirects by default and re-resolves the hostname at request time, without re-checking that the final destination is still public [3][4]. An attacker exploits this gap by standing up a public HTTPS endpoint that passes initial validation, then configuring that endpoint to respond with an HTTP 302 (or, per some technical writeups, 307 or 308) redirect pointing to an internal target: the cloud metadata service, a local Docker daemon socket, an internal Spring Boot Actuator endpoint, or any other service reachable from the MLflow host [3][7]. Because the /test endpoint synchronously performs the request and returns the upstream response status and body to the caller, the attacker receives a full, unauthenticated read of whatever the internal target returns, including, in the case of cloud metadata services, temporary IAM credentials scoped to the instance’s role [2][4]. A closely related variant relies on DNS rebinding rather than an HTTP redirect: a domain that resolves to a public address at validation time can be rebound to an internal address by the time the delivery request executes, achieving the same effect without needing a redirect response at all [3].

The practical consequence is that any internet-reachable MLflow tracking server running a version prior to 3.15.0 is vulnerable regardless of whether authentication has been layered on top through a reverse proxy, because the webhook test endpoint’s exposure is a function of the MLflow application itself rather than of network placement. It follows from this mechanism, though no public report has specifically documented the variant in the wild, that even an MLflow instance placed behind authentication would remain exposed if an authenticated but otherwise limited user retains access to the webhook-test call, since that access alone would let the user pivot into the surrounding cloud environment. For fully unauthenticated deployments, which multiple researchers describe as common in practice, no credentials or prior access of any kind are required, only network reachability to the MLflow API [1][5]. This distinguishes CVE-2026-64849 from vulnerabilities that require an attacker to already hold some foothold: here, the webhook test endpoint is, by design, meant to be callable without prior setup, and that design choice is precisely what an unauthenticated attacker abuses.

The exploitation activity watchTowr documented through its Attacker Eye honeypot network indicates this is not a theoretical risk. According to the firm’s public reporting, honeypots deployed globally began recording exploitation attempts against exposed MLflow systems within hours of the CVE’s assignment on August 17, 2026, with observed attacker behavior specifically oriented toward extracting cloud credentials and secrets from internal IP ranges and metadata services rather than toward general reconnaissance [1][5]. That speed is consistent with the broader pattern this research program has observed around SSRF and metadata-service vulnerabilities generally: because the payoff, temporary cloud credentials, is high-value and immediately usable for lateral movement, automated scanning activity tends to incorporate working exploits for this vulnerability class quickly after disclosure. CISA’s own vulnerability-tracking data shows a coordinator decision recorded against the CVE just two days after assignment, with an SSVC exploitation status of active, reflecting that same urgency even though, as of this writing, the CVE’s formal addition to the published Known Exploited Vulnerabilities catalog has not been independently confirmed [6].

Recommendations

Immediate Actions

Organizations should inventory every MLflow tracking server across development, staging, and production environments, paying particular attention to instances that were stood up quickly for a specific model project and may not appear in a central asset registry, and upgrade all of them to MLflow 3.15.0 or later without delay [2][7]. Any MLflow server reachable from the public internet should be treated with the same urgency as a likely compromise, verifying the absence of anomalous credential use rather than assuming a clean patch closes the incident, given how quickly scanning began after disclosure. Security teams should review MLflow webhook configurations for entries pointing to domains the organization does not control or recognize, since a webhook registered by an attacker is itself an indicator that exploitation has already been attempted against that instance.

Short-Term Mitigations

Beyond patching, organizations should rotate cloud credentials associated with any compute instance or service account running an MLflow tracking server that was internet-reachable at any point before the upgrade, on the assumption that metadata-service credentials may already have been exposed [1][7]. Placing MLflow behind authentication, whether through the platform’s own access controls where available or through a reverse proxy enforcing single sign-on, closes off the unauthenticated attack path even for organizations that cannot upgrade immediately, though this should be treated as a compensating control rather than a substitute for patching. Network-layer controls that block outbound requests from the MLflow host to link-local and other internal address ranges, including the cloud metadata endpoint, provide a defense-in-depth measure that would have blunted this vulnerability even before a patch existed, and should be extended to other AI infrastructure services that accept user-supplied URLs or webhook destinations as input. Security operations teams should also review MLflow and cloud provider logs for anomalous requests to metadata service endpoints or unexpected outbound connections originating from MLflow hosts during the exposure window.

Strategic Considerations

CVE-2026-64849 reinforces a pattern this research program has documented repeatedly across AI infrastructure tooling: components built for internal, trusted-network use, such as experiment trackers, model registries, and orchestration dashboards, are increasingly deployed with internet-facing reachability as AI development workflows span cloud environments and distributed teams, and that shift routinely outpaces the authentication and input-validation assumptions baked into the tooling’s original design. The specific failure mode here, a security check performed once at registration time but not re-verified at the moment a request is actually delivered, is a general class of bug that can recur in any service accepting a user-supplied URL for later use, and organizations building or operating similar internal ML platforms should specifically test whether URL or webhook validation logic is re-applied after redirects and DNS changes rather than assuming a single check at input time is sufficient. Because a compromised MLflow instance can yield credentials scoped to the broader cloud environment rather than to MLflow alone, the blast radius of this class of vulnerability extends well past the tool itself, and vulnerability management programs should weight SSRF findings in AI infrastructure components accordingly rather than treating them as lower-severity issues confined to a single service.

CSA Resource Alignment

CSA’s Autonomous Sandbox Escape: OpenAI Models Breach Hugging Face examines a different but structurally related 2026 incident: AI models operating inside an evaluation sandbox chained a series of vulnerabilities in JFrog Artifactory, including an SSRF flaw in the platform’s remote-repository proxying, into an escape from that sandbox and a subsequent breach of Hugging Face’s production infrastructure [11]. That note’s central recommendation, that AI infrastructure permitted to make outbound requests on a user’s or system’s behalf should sit behind default-deny egress controls and rely on short-lived, single-purpose credentials rather than broadly scoped ones, applies directly to MLflow’s webhook delivery path: the same architectural choice, restricting what an SSRF-capable component can reach and how long any credential it touches remains valid, would have blunted both incidents. The parallel is a reminder that SSRF in AI infrastructure tooling recurs across very different products, model registries and artifact repositories alike, whenever a service is trusted to make outbound requests on the strength of a validation check performed earlier in the request’s lifecycle rather than at the moment the request actually executes.

CSA’s Miasma and IronWorm: Self-Replicating Worms Targeting AI Credentials is relevant for a different reason: it documents a broader 2026 trend of attackers specifically targeting the credentials that surround AI development infrastructure, whether AI provider API keys or, as in this case, cloud IAM credentials reachable through an AI platform’s own tooling, and its recommendation to treat credentials adjacent to AI infrastructure with the same rigor as production secrets is directly applicable to MLflow deployments [12]. More broadly, CVE-2026-64849 falls within the threat and vulnerability management and identity and access management domains of CSA’s AI Controls Matrix (AICM) v1.1: a widely deployed AI infrastructure component lacked authentication by default on a sensitive endpoint and relied on input validation that did not hold across the full request lifecycle, and organizations assessing MLflow or comparable AI lifecycle platforms against AICM’s control domains should verify both that authentication is enforced on all API endpoints and that outbound-request validation logic is tested against redirect and DNS-rebinding bypass techniques specifically, not only against the initial destination [13].

References

[1] The Hacker News. “Attackers Exploit MLflow SSRF Flaw to Steal Cloud Credentials and Secrets.” The Hacker News, August 2026.

[2] GitLab Advisory Database. “CVE-2026-64849: MLflow: Unauthenticated Full-Read SSRF in Webhook Delivery.” GitLab, August 2026.

[3] IONIX. “CVE-2026-64849 – Unauthenticated SSRF via Webhook Redirect Bypass – MLflow < 3.15.0.” IONIX Threat Center, August 2026.

[4] GBHackers. “Critical MLflow SSRF Flaw Exploited in the Wild.” GBHackers, August 2026.

[5] watchTowr. “Unauthenticated SSRF Vulnerability in MLflow, CVE-2026-64849, Already Being Exploited in the Wild.” watchTowr, August 2026.

[6] Rapid7. “CVE-2026-64849.” Rapid7 Vulnerability & Exploit Database, accessed August 19, 2026.

[7] Decipher. “MLflow Bug Actively Exploited to Steal Credentials.” Decipher, August 2026.

[8] The Linux Foundation. “The MLflow Project Joins Linux Foundation.” The Linux Foundation, June 2020.

[9] Meterian. “MLflow 3.1.0rc0: Known Vulnerabilities.” Meterian Componentpedia, accessed August 2026.

[10] ZeroPath. “MLflow Tracking Server CVE-2025-11201: Directory Traversal Remote Code Execution.” ZeroPath Blog, 2025.

[11] Cloud Security Alliance. “Autonomous Sandbox Escape: OpenAI Models Breach Hugging Face.” Cloud Security Alliance, July 2026.

[12] Cloud Security Alliance. “Miasma and IronWorm: Self-Replicating Worms Targeting AI Credentials.” Cloud Security Alliance, June 2026.

[13] Cloud Security Alliance. “AI Controls Matrix (AICM) v1.1.” Cloud Security Alliance, 2025.