CVE-2026-64849: MLflow Server-Side Request Forgery - What It Means for Your Business and How to Respond

Introduction

A critical vulnerability in a widely used machine learning platform has entered active exploitation, putting organizations that rely on artificial intelligence and data science tools at immediate risk. CVE-2026-64849 affects MLflow, an open-source platform for managing machine learning models, experiments, and related workflows. Attackers can abuse the flaw without credentials to reach internal systems and cloud metadata services, potentially harvesting credentials that unlock broader cloud environments.

Businesses across the United States and Canada that deploy MLflow for model tracking, registry, or production pipelines face exposure of sensitive operational data and cloud accounts. The issue carries a critical severity rating and appears on the U.S. Cybersecurity and Infrastructure Security Agency’s Known Exploited Vulnerabilities catalog, signaling confirmed real-world attacks.

This post explains the business consequences of the vulnerability, illustrates realistic impact scenarios, helps you determine whether your environment is affected, and outlines clear next steps. Technical details appear only in the appendix for security and IT teams.

S1 — Background & History

CVE-2026-64849 was publicly disclosed on August 17, 2026, through a GitHub security advisory. It affects the MLflow tracking server, specifically versions starting from 3.3.0 up to but not including 3.15.0. The vulnerability was reported by independent security researchers and assigned a CVSS score of 9.3, rated Critical.

In plain language, the flaw is a server-side request forgery issue. It allows an unauthenticated attacker who can reach the MLflow server to trick it into making requests to internal network locations or cloud metadata endpoints and then return the results. This effectively turns the MLflow server into a proxy for probing and reading restricted resources.

Key timeline events include private discovery in June 2026, public disclosure and CVE assignment on August 17, addition to the CISA Known Exploited Vulnerabilities catalog on August 19, and a federal remediation deadline of September 2, 2026. The official fix shipped in MLflow version 3.15.0.

S2 — What This Means for Your Business

For business leaders, this vulnerability translates into concrete operational, financial, and reputational exposure. An attacker who reaches a vulnerable MLflow instance can extract cloud credentials, such as temporary access keys used by the server’s underlying cloud role. Those credentials often grant permissions far beyond the machine learning environment, opening paths to data stores, compute resources, and other services.

Operations suffer when stolen credentials enable unauthorized access or when security teams must take systems offline for emergency response. Data risk includes exposure of model artifacts, training datasets, experiment results, and any secrets reachable from the compromised server. Reputation damage follows public reports of credential theft or secondary breaches, especially for firms handling regulated data or customer information.

Compliance obligations intensify for organizations subject to U.S. and Canadian frameworks. Financial institutions, healthcare providers, and companies handling personal information face heightened scrutiny under regulations that require timely patching of known exploited flaws and demonstration of reasonable security controls. Failure to address a CISA-listed vulnerability can complicate audit findings, insurance claims, and contractual obligations with partners who demand evidence of secure software supply chains.

In short, the vulnerability converts a specialized machine learning tool into a potential entry point for broader cloud compromise, with cascading effects on daily operations, data protection, and regulatory standing.

S3 — Real-World Examples

Regional Bank Model Risk Team: A mid-sized financial institution runs MLflow to track credit-risk models. An unauthenticated attacker reaches the tracking server, retrieves cloud credentials, and uses them to access customer data lakes. The bank faces regulatory notification requirements, temporary suspension of model deployment pipelines, and costly forensic investigation while competitive product launches are delayed.

Healthcare Analytics Provider: A Canadian health-data analytics firm uses MLflow for clinical prediction models. Exploitation allows extraction of instance metadata containing access tokens. Sensitive de-identified patient datasets and model intellectual property become reachable, triggering privacy breach assessments under provincial health privacy laws and eroding trust among hospital partners who supply data.

Manufacturing Predictive Maintenance Startup: A U.S. industrial firm employs MLflow to manage sensor-based failure-prediction models across factory sites. Attackers leverage the flaw to map internal services and steal credentials that control edge compute resources. Production monitoring is disrupted, forcing manual oversight and raising the risk of unplanned downtime across multiple plants.

Retail Demand-Forecasting Operation: A national retailer hosts MLflow for inventory forecasting. Successful exploitation yields credentials that permit access to shared cloud storage containing proprietary sales models and supplier pricing data. Competitors could gain insight into demand patterns, while the retailer incurs remediation costs and potential contractual penalties from data-sharing agreements.

S4 — Am I Affected?

• You are running MLflow version 3.3.0 or later but have not yet upgraded to 3.15.0 or newer.
• Your MLflow tracking server is reachable from networks outside your tightly controlled internal segments, including any internet-facing or partner-accessible instances.
• Authentication is not enabled or is misconfigured on the default MLflow server deployment.
• Your MLflow instance runs on a cloud virtual machine or container that holds an IAM role, service account, or equivalent with access to metadata services or internal resources.
• Your organization uses MLflow for model registry, experiment tracking, or webhook integrations in production or staging environments.
• You have not applied network controls that block the server from initiating outbound requests to cloud metadata endpoints or internal address ranges.

Key Takeaways

• CVE-2026-64849 is a critical, actively exploited flaw in MLflow that allows unauthenticated access to internal and cloud resources, including credentials.
• Businesses face risks to operations, data confidentiality, reputation, and regulatory compliance across the United States and Canada.
• Realistic impact scenarios span banking, healthcare, manufacturing, and retail, illustrating how specialized tools can become broader attack vectors.
• Organizations should confirm whether they run affected MLflow versions and whether the tracking server is network-reachable without proper authentication.
• Prompt patching to version 3.15.0 or later, combined with network and access controls, remains the primary path to risk reduction.

Call to Action

Understanding exposure is the first step; validating and hardening your environment is the next. IntegSec helps organizations identify vulnerable MLflow deployments, assess residual risk, and implement lasting controls through targeted penetration testing and risk-reduction engagements. Contact us today at https://integsec.com to schedule an assessment and strengthen your defenses against this and similar threats.

TECHNICAL APPENDIX (security engineers, pentesters, IT professionals only)

A — Technical Analysis

The root cause is a time-of-check to time-of-use weakness in MLflow’s webhook URL validation. The unauthenticated POST /api/2.0/mlflow/webhooks/{id}/test endpoint invokes _validate_webhook_url() in mlflow/utils/validation.py, which resolves the supplied hostname and rejects non-public IP addresses. However, the subsequent delivery logic in mlflow/webhooks/delivery.py follows HTTP redirects and re-resolves the hostname without pinning the previously validated address. This permits attackers to supply an initially valid public URL that redirects to internal addresses or cloud metadata services such as 169.254.169.254.

The attack vector is network, complexity is low, privileges required are none, and user interaction is none. Scope is changed because the vulnerability allows the server to access resources beyond its intended boundary. The CVSS 3.1 vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N. The vulnerability maps to CWE-918 (Server-Side Request Forgery). Full details are recorded in the NVD entry for CVE-2026-64849 and the GitHub advisory GHSA-7gwp-5pfp-969j. Affected component is the model-registry webhooks functionality present in versions greater than or equal to 3.3.0 and less than 3.15.0.

B — Detection & Verification

Version enumeration can be performed by querying the MLflow API endpoint that returns server version information or by inspecting installed package metadata with pip show mlflow or equivalent container image labels. Scanner signatures exist in common vulnerability scanners and nuclei templates that target the webhook creation and test endpoints. Log indicators include unexpected POST requests to /api/2.0/mlflow/webhooks followed by /test, particularly those containing external or attacker-controlled URLs. Behavioral anomalies appear as the MLflow process initiating outbound HTTP connections to internal RFC 1918 addresses, link-local metadata endpoints, or previously unseen hostnames shortly after webhook test calls. Network exploitation indicators include traffic from the MLflow host to 169.254.169.254 or similar cloud metadata services coinciding with webhook API activity, as well as DNS queries that resolve to public addresses then immediately re-resolve to private ones (DNS rebinding patterns).

C — Mitigation & Remediation

1. Immediate (0–24h): Upgrade all MLflow instances to version 3.15.0 or later. If immediate upgrade is impossible, restrict network access to the tracking server so that only trusted management hosts can reach the API ports, and block outbound connections from the MLflow host to cloud metadata endpoints and internal address ranges.
2. Short-term (1–7d): Enable authentication on the MLflow tracking server, rotate any cloud credentials or IAM roles associated with the host, and review access logs for signs of prior exploitation. Apply host-based firewall rules that prevent the process from connecting to non-public destinations.
3. Long-term (ongoing): Maintain an inventory of all MLflow deployments, enforce automatic updates or regular patch cycles for machine-learning tooling, and implement continuous monitoring for anomalous outbound requests from model-tracking servers. Prefer network segmentation that isolates ML infrastructure from production data stores and credential-bearing services.

The official vendor patch in 3.15.0 introduces connection-time IP validation that covers redirect targets and mitigates DNS rebinding. Interim mitigations for environments unable to patch immediately center on network isolation and outbound traffic filtering.

D — Best Practices

• Pin resolved IP addresses during URL validation and re-validate the peer address after every redirect or connection establishment.
• Disable or tightly restrict unauthenticated webhook and test endpoints on any internet-reachable or multi-tenant MLflow deployment.
• Apply least-privilege IAM roles or service accounts to hosts running MLflow so that metadata services, if reachable, yield minimal credentials.
• Enforce egress filtering that blocks access to link-local and private address ranges from machine-learning infrastructure.
• Monitor and alert on creation of webhooks that point to external or unexpected destinations, combined with subsequent test invocations