The active exploitation of CVE-2026-64849 in MLflow is another reminder that AI infrastructure is quickly becoming part of the mainstream attack surface. MLflow is widely used for managing machine-learning experiments, models and deployments, and when its Tracking Server is exposed or insufficiently protected, it can provide attackers with a valuable bridge into the surrounding cloud environment. In this case, the vulnerability is an unauthenticated server-side request forgery, or SSRF, issue affecting MLflow versions prior to 3.15.0. An attacker who can reach the MLflow Tracking Server can abuse model-registry webhook functionality to make requests to internal services that would normally be inaccessible from the Internet.

The most serious aspect of this vulnerability is its potential to reach cloud metadata services. Cloud workloads frequently rely on metadata endpoints to provide temporary credentials, instance information and other sensitive configuration data to applications running inside the environment. By forcing a vulnerable MLflow server to communicate with these internal endpoints, an attacker may be able to obtain cloud credentials and secrets without first compromising an authenticated user. According to the reported research, attackers are already attempting exactly this, targeting well-known internal addresses associated with cloud metadata services and trying to exfiltrate the information returned.

The speed of exploitation should also concern defenders. The vulnerability was assigned CVE-2026-64849 on August 17, 2026, and watchTowr reported observing indiscriminate scanning for exposed MLflow instances within hours. Once again, the comfortable period organisations once expected between vulnerability disclosure and meaningful exploitation has largely disappeared. Internet-wide scanning, automated vulnerability discovery and reusable exploitation frameworks mean that a newly disclosed critical flaw can become part of an attacker's toolkit almost immediately. For externally accessible infrastructure, patching in days rather than weeks is increasingly becoming the realistic security requirement.

An important technical detail is that this vulnerability reportedly bypasses earlier protections because of the way web redirects are handled. That is a useful lesson in SSRF defence generally. Blocking obvious metadata addresses or validating only the initial destination is often insufficient if the application follows redirects, resolves DNS dynamically or permits requests through multiple URL-processing paths. Effective SSRF protection requires strict destination validation throughout the entire request chain, restrictions on private and link-local address ranges, controlled redirect behaviour and preferably an outbound network policy that prevents applications from reaching services they have no legitimate reason to access.

This incident also illustrates why cloud security cannot rely only on protecting credentials at the login layer. Temporary workload credentials can be extremely powerful, and an attacker does not necessarily need to steal a developer's password if an application can be manipulated into retrieving credentials on the attacker's behalf. Organisations therefore need to consider the permissions assigned to the underlying MLflow host or workload. Even when SSRF occurs, the damage can be substantially reduced if the instance identity follows least privilege and cannot freely access sensitive storage, secrets, administrative APIs or other cloud resources.

Another lesson is that AI and machine-learning environments deserve the same network segmentation and access controls as any other critical infrastructure. Development teams sometimes expose tools such as experiment trackers, notebook servers, model registries and orchestration platforms because they are viewed as engineering utilities rather than production systems. Attackers, inconveniently, do not share these organisational distinctions. To them, an exposed ML platform may represent credentials, datasets, proprietary models, internal network access and potentially a path toward broader cloud compromise.

Organisations running MLflow should therefore prioritise upgrading affected installations to version 3.15.0 or later, particularly where the Tracking Server is accessible from untrusted networks. Administrators should also review historical logs for suspicious webhook activity, unexpected requests toward internal or link-local addresses, unusual outbound connections and evidence that metadata endpoints may have been contacted. If there is any indication that credentials could have been exposed, simply installing the patch is not enough. Potentially compromised credentials and tokens should be rotated, associated cloud activity should be reviewed, and the permissions of the affected workload should be reassessed. The researchers specifically recommend patching exposed systems, reviewing audit logs and determining whether sensitive credentials have already been accessed.

The same report also highlights active scanning against FUXA, an open-source SCADA and HMI platform used in operational technology environments. CVE-2026-25895, rated CVSS 9.5, combines missing authentication with path traversal and can allow an unauthenticated remote attacker to write arbitrary files and potentially achieve remote code execution. The presence of active reconnaissance against critical vulnerabilities in both AI infrastructure and industrial software at essentially the same time reinforces how broadly automated attacker infrastructure now operates. Attackers are not necessarily selecting one industry or technology stack; they are continuously searching the Internet for whichever vulnerable systems are available.

The broader security lesson from the MLflow vulnerability is that outbound traffic deserves almost as much scrutiny as inbound traffic. Traditional perimeter security concentrates heavily on preventing attackers from reaching servers. SSRF turns that model around: the attacker persuades a trusted server to make the connection for them. From the network's perspective, the request may originate from an authorised internal workload, but from a security perspective its context is entirely malicious. Detecting these attacks therefore requires visibility into what applications are communicating with, whether those destinations are expected and whether the behaviour makes sense for that particular workload.

As AI platforms become connected to larger datasets, cloud services, development pipelines and production environments, compromising the infrastructure around the model may prove considerably easier than attacking the model itself. Protecting AI systems therefore cannot stop at securing prompts and models. It must include the APIs, management interfaces, service identities, cloud permissions, network paths and data stores surrounding them. CVE-2026-64849 is ultimately less a story about one MLflow vulnerability and more a warning that AI infrastructure has become valuable infrastructure, and attackers have noticed.

Two critical vulnerabilities impacting MLflow, an open-source artificial intelligence (AI) platform, and FUXA, an open-source, web-based SCADA / HMI software built for operational technology (OT) and industrial automation, are witnessing malicious scanning and exploitation efforts. According to independent reports from watchTowr and VulnCheck, the vulnerabilities in question are as follows -

Source: Attackers Exploit MLflow SSRF Flaw to Steal Cloud Credentials and Secrets via The Hacker News — published 18 Aug 2026.