Exposed MLflow servers need an update

What has changed

On 19 August, the US Cybersecurity and Infrastructure Security Agency added CVE-2026-64849 to its Known Exploited Vulnerabilities catalogue. CISA describes a server-side request forgery weakness in MLflow that can let an attacker reach internal services or cloud metadata and receive the response. Inclusion in the catalogue means CISA has evidence of exploitation in the wild. The agency records use in ransomware campaigns as unknown; that is not evidence for or against such use.

MLflow published its advisory on 17 August. The project says versions before 3.15.0 are affected and identifies 3.15.0 as the first patched release. CISA's remediation deadline applies to US federal agencies covered by its directive, not UK organisations, but the exploitation finding makes prompt inventory and remediation sensible for any business that runs the affected service.

Why the service boundary matters

MLflow Tracking Server supports experiment tracking and model-registry workflows. The vendor advisory says the vulnerable webhook delivery path could be made to request resources on private, loopback or cloud-metadata addresses. On the default open-source server configuration described by MLflow, the relevant webhook interfaces do not require authentication. A reachable tracking service could therefore become a route towards systems and data that are not otherwise exposed to the same user.

The likely consequence depends on where MLflow runs and what that host can reach. Internal APIs, management services and instance metadata may carry different risks, while cloud credentials are limited by the permissions assigned to the workload. Neither source says that every exposed server has been compromised. Defenders should distinguish confirmed vulnerable versions and network reachability from local evidence of misuse.

What defenders should do

Inventory MLflow Tracking Servers across developer workstations, shared test environments, build systems and cloud workloads. Confirm the running package version and whether the service is reachable from the internet, employee devices, supplier connections or neighbouring workloads. Update affected installations to MLflow 3.15.0 or later through the supported deployment process, then confirm the version actually running after services or containers restart.

Restrict the tracking service to the users and systems that need it. MLflow says the flaw bypasses the earlier webhook URL validation, so that validation is not a substitute for the fixed release. Authentication and narrow network paths remain useful layers, but they should not be presented as eliminating the need to update. Review the permissions and network access granted to the MLflow host so that a service compromise does not inherit more reach than its work requires.

Where an affected server was reachable, preserve relevant application, proxy, network and cloud audit records before making disruptive changes. Review them proportionately for unexpected webhook activity, unusual requests from the MLflow host and access to sensitive internal services. CISA confirms exploitation of the vulnerability generally, not compromise of a particular organisation; escalate through the incident process when local evidence supports it.

• Locate every MLflow Tracking Server and name its owner.
• Confirm the installed and running version, not only the deployment manifest.
• Update releases below 3.15.0 to a supported fixed release.
• Limit service reachability and review the host's cloud and network permissions.
• Preserve and assess evidence where an affected service was reachable.

The Beekeeper view

Developer platforms often sit between code, credentials and cloud infrastructure. That makes ownership and network boundaries as important as the package update: a forgotten experiment server can have a surprisingly useful view of the rest of the estate.

Patch the known weakness, then keep the architectural lesson. Outbound requests made by an application cross a trust boundary too. Services that can fetch remote resources need narrow reach, modest workload permissions, useful logs and an owner who can update them without archaeology.