Attackers have started exploiting a recent MLflow SSRF vulnerability to steal sensitive data, including credentials and secrets. The issue targets exposed components of MLflow’s tracking server, enabling attackers to send HTTP requests to internal endpoints and potentially reach cloud metadata services.
Because this weakness is being actively used “in the wild,” organizations running MLflow are urged to patch promptly, review audit logs, and verify whether any secrets could have been exposed.
What MLflow does and why it matters
MLflow is an open source platform used to manage the machine learning lifecycle—from experimentation to deployment in production. Teams use it to organize workflows and support production scenarios for AI agents, large language models (LLMs), and machine learning models.
Its popularity is reflected in its large download numbers and broad community adoption. That wide usage makes vulnerabilities in widely deployed MLflow components especially concerning for defenders.
The vulnerability at a glance: CVE-2026-64849
The exploited defect is tracked as CVE-2026-64849 and has a CVSS score of 9.3, indicating high severity. According to the available advisory details, the problem is an unauthenticated server-side request forgery (SSRF) condition.
In practice, SSRF flaws let an attacker coerce a server to make requests it should not make. In this case, the tracking server can be driven to send HTTP requests to internal endpoints that are normally not reachable from the public internet.
Why the Tracking Server is exposed
As described in the advisory, the root cause is that the default MLflow Tracking Server (commonly referred to as the mlflow server) exposes the model-registry webhooks API without authentication.
This means an attacker does not need valid credentials to interact with the webhooks interface. One of the exposed endpoints can also return the upstream response status and body back to the caller, which increases the attacker’s ability to understand what they are reaching internally.
Additionally, an SSRF protection introduced in version 3.10.0 could be bypassed. That detail matters because it suggests that simply using a “not the oldest” version may not be enough if you are still within the affected range.
How exploitation enables cloud credential theft
Security monitoring guidance warns that attackers can leverage the MLflow SSRF to reach cloud metadata services directly. Cloud metadata endpoints often expose identity-related information that can be used to obtain or mint access tokens for cloud resources.
By pulling information from these services, threat actors may exfiltrate cloud credentials and secrets. This is one of the most damaging outcomes of SSRF, because it can turn an application exposure into broader compromise of cloud infrastructure.
What WatchTowr observed
An attack surface management firm noted that exploitation began very quickly after the CVE was assigned—within hours. Their assessment also indicates targeting of cloud-hosted MLflow instances, which aligns with the idea that systems exposed to the internet are more likely to be found and abused rapidly.
The firm’s key message is straightforward: if MLflow is deployed and publicly reachable (or otherwise reachable by an attacker), the risk is urgent.
Affected versions and immediate actions
All MLflow versions before 3.15.0 are reported as affected. That means organizations should not only consider the presence of the vulnerable component, but also the exact version of MLflow deployed across environments.
To reduce risk, prioritize patching any exposed systems without delay. In addition to updating, review internal and external audit logs for indicators of compromise. Also check whether sensitive credentials may have been exposed during the window of exploitation.
If MLflow is used in multiple environments (for example, staging and production), verify each location. Attackers often probe whichever environments are reachable, not just the “main” one.
KEV listing and the pressure to patch quickly
The US cybersecurity agency added CVE-2026-64849 to its Known Exploited Vulnerabilities (KEV) catalog. KEV additions typically signal that there is evidence of active exploitation, and the listing comes with expectations for how quickly federal agencies should remediate.
While organizations outside the federal scope can set their own timelines, a KEV listing is a strong signal that delays increase the odds that additional attackers will find and compromise exposed MLflow deployments.
Practical defense checklist for teams running MLflow
If you maintain MLflow deployments, focus on measures that reduce exposure and increase detection. Consider the following steps:
- Patch urgently: update MLflow to a version that is not affected (versions earlier than 3.15.0 are listed as vulnerable).
- Verify exposure: identify whether the tracking server endpoints are reachable from untrusted networks.
- Review audit logs: look for suspicious request patterns involving the model-registry webhooks API and any unusual internal outbound activity.
- Assess credential exposure: determine whether cloud credentials or secrets could have been accessed during potential exploitation.
- Harden access paths: restrict who can reach MLflow components and ensure authentication is enforced where applicable.
Because SSRF can be leveraged in multiple ways, treat “it’s just one endpoint” as “it may be a pivot.” The ability to retrieve upstream responses can provide attackers with feedback loops that improve follow-on activity.
Related vulnerability context
This development fits a wider pattern in application security: critical flaws in software ecosystems—especially those tied to authentication, exposed APIs, or server-to-server request handling—are frequently weaponized quickly. Reports of other actively exploited issues across popular platforms underscore the importance of rapid patching and ongoing exposure management.
Even when a vulnerability seems narrowly scoped, attackers often automate scanning and exploitation, targeting whatever systems are reachable and misconfigured.
Conclusion
The MLflow SSRF vulnerability tracked as CVE-2026-64849 is not theoretical anymore. Publicly exposed tracking server components can be abused to trigger internal HTTP requests and potentially reach cloud metadata services, enabling theft of cloud credentials and secrets.
If your organization runs MLflow, act now: patch systems to a safe version, review audit logs for signs of compromise, and validate whether any credentials may have been exposed. With active exploitation and a KEV listing, remediation speed is a key part of risk control.
Source: https://www.securityweek.com/mlflow-vulnerability-exploited-for-cloud-credential-theft/
