A critical bug in MLflow, the open-source platform that tens of thousands of AI teams use to track machine learning experiments, is now on the U.S. government’s list of flaws being actively used in attacks. CISA added CVE-2026-64849 to its Known Exploited Vulnerabilities catalog on August 19, 2026, warning that hackers are exploiting the flaw to reach into AWS, Google Cloud, and Azure metadata services and walk away with live cloud credentials.
The bug carries a CVSS score of 9.3 out of 10. It requires no login, no user interaction, and no special access. An attacker who can reach an exposed MLflow tracking server can trick it into leaking IAM tokens, access keys, or managed-identity credentials straight from the machine it runs on. Security researchers say scanning for vulnerable servers began within hours of the CVE going public, and confirmed incidents already involve cryptocurrency mining and new IAM users planted for persistence.
What CVE-2026-64849 Actually Is
MLflow’s webhook system lets teams trigger notifications when a model run finishes or a registry event fires. To stop that feature from being abused as an SSRF gateway, MLflow validates the target URL before sending a test request. The problem sits in how that validation interacts with redirects. The unauthenticated endpoint POST /api/2.0/mlflow/webhooks/{id}/test checks that the original URL points to a public address, then hands the actual request off to a delivery function that resolves the hostname again and follows any redirect it receives, according to the CVE entry published by NVD.
That gap between check and use is a textbook time-of-check-to-time-of-use flaw. Snyk’s advisory lays out the exploit path in plain terms: an attacker registers a webhook pointed at a server they control, which returns a normal public response the first time MLflow checks it, then responds to the actual delivery request with an HTTP 302 redirect to 169.254.169.254, the link-local address cloud providers use for instance metadata. MLflow follows that redirect without re-checking whether the new address is private, and because the test endpoint echoes the full response body back to the caller, the attacker reads the metadata service’s reply directly in their browser or script.
The flaw is tracked as CWE-918, the standard classification for server-side request forgery. It affects every MLflow release before version 3.15.0, which shipped July 31, 2026, and which fixed the issue by adding a component called SSRFProtectedHTTPAdapter that pins and re-validates the connecting IP address at socket level, before any HTTP exchange happens, per the patch referenced by Endor Labs’ vulnerability database.
CVE-2026-64849 at a Glance
| Detail | Value |
|---|---|
| CVE identifier | CVE-2026-64849 |
| CVSS v3.1 score | 9.3 (Critical) |
| EPSS percentile | 95th or higher |
| Weakness class | CWE-918 (Server-Side Request Forgery) |
| Affected versions | All MLflow releases prior to 3.15.0 |
| Patched version | MLflow 3.15.0 (released July 31, 2026) |
| Authentication required | None |
| Added to CISA KEV | August 19, 2026 |
| Federal patch deadline | September 2, 2026 |
Why an MLOps Tool Now Sits Next to Firewalls on the KEV List
MLflow was created at Databricks in 2018 by Matei Zaharia, the engineer who also built Apache Spark, and it moved under the vendor-neutral Linux Foundation’s LF AI & Data umbrella in 2020. That governance shift did not slow adoption. MLflow’s own project documentation states the package now sees more than 30 million downloads a month and carries over 26,000 stars on GitHub, numbers that put it among the most widely deployed pieces of AI infrastructure software outside the major cloud vendors’ own tooling.
That scale is exactly what makes this bug dangerous. MLOps platforms like MLflow typically run with elevated cloud permissions by design, because they need to pull training data from storage buckets, push model artifacts to registries, and spin up compute for training jobs. A tracking server that gets exposed to the open internet, or even just to an internal network an attacker has already touched, becomes a shortcut straight to the credentials that unlock all of that.
What Happens After the Metadata Service Answers
Reaching 169.254.169.254 is only step one. On AWS, that endpoint hands back temporary security credentials tied to whatever IAM role the EC2 instance or container is running under. On Azure, the equivalent Instance Metadata Service issues managed-identity tokens. On GCP, the metadata server serves service-account tokens the same way. Once an attacker has one of those, they can call the cloud provider’s own APIs as if they were the compromised workload.
Recatools, which has tracked exploitation of this specific bug, reports confirmed incidents in which attackers used stolen credentials to enumerate other cloud resources, deploy cryptocurrency miners on compute they didn’t pay for, and create brand-new IAM users and roles to maintain access even after the original hole gets patched. That last step is the one that turns a single vulnerability into a lingering incident response problem, because rotating one leaked key does nothing if the attacker already planted a second identity.
A Familiar Attack Pattern, Not a New One
Cloud metadata SSRF is one of the oldest tricks in cloud security, and MLflow is far from the first application to fall to it. The clearest precedent is Capital One’s 2019 breach, in which an attacker exploited a misconfigured web application firewall to reach AWS’s metadata service and pull IAM credentials tied to an over-permissioned role. That single request chain exposed data on roughly 106 million people, including about 140,000 Social Security numbers and 80,000 linked bank account numbers. The U.S. Office of the Comptroller of the Currency fined Capital One $80 million over the incident in August 2020, and the bank separately agreed to a $190 million class-action settlement with affected customers in December 2021. AWS shipped IMDSv2, a token-gated version of its metadata service designed specifically to blunt this class of attack, later that same year.
Seven years on, the same request-forgery trick keeps resurfacing in new software. GitLab’s CVE-2021-22214 let unauthenticated requests reach internal network resources through its webhook and metrics integrations. This year alone has already produced a run of similar cases: an SSRF in Azure MCP Server tracked as CVE-2026-26118 (CVSS 8.8) that reaches Azure’s IMDS to steal managed-identity tokens, an SSRF in the low-code platform ToolJet (CVE-2026-55412) that bypassed a private-IP filter to hit Azure IMDS on a production AKS cluster, and a redirect-based bypass in the AVideo platform (CVE-2026-43884, CVSS 7.7) that reaches the AWS metadata path directly. The mechanism barely changes. What changes is which application gets caught not validating a redirect.
Cloud Metadata SSRF Incidents, 2019-2026
| Incident / CVE | Year | Target | CVSS | Outcome |
|---|---|---|---|---|
| Capital One breach (AWS WAF SSRF) | 2019 | AWS IMDS | N/A (pre-CVE era) | 106M records exposed, $80M OCC fine, $190M settlement |
| GitLab CE/EE, CVE-2021-22214 | 2021 | Internal network / metadata | 8.6 | Unauthenticated internal SSRF via webhooks |
| AVideo, CVE-2026-43884 | 2026 | AWS IMDS | 7.7 | Redirect-based SSRF protection bypass |
| Azure MCP Server, CVE-2026-26118 | 2026 | Azure IMDS | 8.8 | Managed-identity token theft |
| ToolJet RestAPI, CVE-2026-55412 | 2026 | Azure IMDS | Not disclosed | Token theft on production AKS cluster |
| MLflow, CVE-2026-64849 | 2026 | AWS / GCP / Azure metadata | 9.3 | Active exploitation, added to CISA KEV Aug. 19, 2026 |
The Timeline From Patch to Federal Deadline
MLflow’s maintainers shipped the fix in version 3.15.0 on July 31, 2026, roughly three weeks before CISA’s action. That gap matters. SentinelOne’s vulnerability database notes the flaw affects every release before 3.15.0, and once the patch and its accompanying advisory went public, security researchers began indiscriminately scanning the internet for exposed tracking servers within hours, according to reporting reviewed for this story. CISA formally added CVE-2026-64849 to its Known Exploited Vulnerabilities catalog on August 19, 2026, a listing that only happens once the agency has direct evidence of exploitation in the wild rather than theoretical risk.
Under Binding Operational Directive 22-01, that KEV listing triggers a mandatory remediation clock for U.S. federal civilian agencies, which must patch or remove affected MLflow instances by September 2, 2026. Private companies face no legal deadline, but the same clock is a reasonable benchmark: if a vulnerability is dangerous enough that Washington gave itself two weeks to fix it, it is dangerous enough for any enterprise running an internet-reachable or even internally-reachable MLflow server to treat with the same urgency.
How This Compares to Other Cloud Security Incidents This Year
The CISA KEV catalog has grown fast in 2026. Independent trackers mirroring the official feed counted roughly 1,665 total entries as of August 11 and close to 1,685 by August 27, meaning the catalog added around 20 confirmed-exploited vulnerabilities in just over two weeks. MLflow’s addition is notable less for its raw CVSS score, which is high but not unprecedented, and more for what it targets: not a firewall, not a VPN gateway, but a piece of AI development infrastructure that most security teams still treat as internal tooling rather than a production system worth hardening.
That blind spot is showing up across the AI stack. GitLab’s own AI Gateway carried an SSRF (CVE-2026-19889, CVSS 8.2) earlier this year, and IBM’s Langflow project disclosed a comparable metadata-reaching SSRF in its legacy RSS and SearXNG integrations, tracked as CVE-2026-10564. MLOps and agent-orchestration platforms share a common weakness: they are built to make outbound HTTP calls on a schedule, to arbitrary destinations, with elevated cloud permissions attached. That is precisely the shape of application SSRF loves to exploit.
Who Actually Runs an Exposed MLflow Server
MLflow rarely ships as a single, obviously internet-facing product, which is part of why this bug is slow to stamp out. Teams typically stand up a tracking server inside a Kubernetes cluster or on a shared VM, point notebooks and training jobs at it, and never revisit the network configuration once it works. Data scientists, not security engineers, usually own that decision, and the tool’s own defaults have historically prioritized ease of setup over lockdown. A server that was only ever meant to be reachable from a company VPN can end up exposed after a load balancer misconfiguration, a stale firewall rule, or a lift-and-shift to a new cloud account nobody re-audited.
That ownership gap shows up in how slowly these bugs get patched compared to internet-facing software like VPN gateways or firewalls, which security teams monitor closely because their exposure is obvious. MLOps tooling tends to sit a layer down, treated as developer infrastructure rather than a production asset, even though the credentials it holds can reach the same cloud accounts as anything else. That mismatch between where a company’s security attention goes and where its actual cloud permissions live is the throughline connecting this incident to almost every other cloud metadata SSRF case on record.
What MLflow Operators Should Do Right Now
The immediate fix is a version upgrade, not a configuration workaround. Teams running self-hosted MLflow tracking servers should confirm their deployment sits on 3.15.0 or later.
pip install --upgrade "mlflow>=3.15.0"
mlflow --versionBeyond the upgrade, security teams reviewing this incident point to the same set of controls that would have blunted it even before a patch existed. Moving cloud workloads to IMDSv2-style token-gated metadata access on AWS, or the equivalent hardened endpoints on Azure and GCP, removes the simple redirect trick as a viable path. Network policies that block application servers from reaching link-local addresses like 169.254.169.254 outright, unless a specific process needs that access, close the same gap at the infrastructure layer regardless of what application-layer bugs show up next. And auditing which IAM roles are actually attached to MLflow’s hosting environment matters just as much as the patch itself, since a tightly scoped role limits the blast radius even if a future SSRF slips through.
Market Impact: MLOps Security Gets a Budget Line
Enterprise security spending has chased whatever category produces the scariest KEV entries, and 2026 has already pushed budgets toward AI supply-chain and MLOps tooling in a way that lagged the broader AI adoption curve for years. A tool with 30 million-plus monthly downloads landing on a federal must-patch list gives CISOs a concrete data point to justify auditing every internal AI pipeline component, not just the customer-facing model endpoints that usually get the security team’s attention first. Expect vendors selling AI security posture management and MLOps scanning tools to point directly at this incident in their sales pitches over the next two quarters.
For Databricks and the Linux Foundation’s LF AI & Data group, which now governs MLflow, the incident is also a governance test. Open-source projects that scale past a certain size start functioning like critical infrastructure whether or not their maintainers planned for that role, and a webhook feature meant for convenience turning into a KEV-listed credential-theft vector is the kind of story that pushes maintainers toward slower, more defensive default configurations even at the cost of some flexibility.
Historical Context: SSRF’s Long Run Against Cloud Metadata
Server-side request forgery has been a top-tier cloud risk since long before MLflow existed. The Capital One breach made the pattern famous in 2019, but the underlying weakness, an application that will fetch a URL on the attacker’s behalf without checking where that URL actually leads once redirects and DNS resolution get involved, is close to two decades old as a web application bug class. What has changed is the payoff. In 2019, reaching cloud metadata meant IAM credentials for one account. In 2026, the same trick reaches into AI pipelines that often touch training data, proprietary model weights, and multiple cloud accounts strung together across a company’s entire ML infrastructure, all from a single exposed tracking server.
Predictions: Where This Story Goes From Here
- Expect at least one more MLOps or agent-framework SSRF to reach CISA’s KEV list before the end of 2026, given how many platforms in that category share the same outbound-webhook design pattern.
- Cloud providers will keep pushing customers toward IMDSv2-equivalent metadata protections as a default rather than an opt-in, likely accelerating enforcement timelines on AWS, Azure, and GCP alike.
- Databricks and the MLflow maintainers will probably ship additional SSRF-hardening changes beyond 3.15.0, including tighter default network egress rules for self-hosted deployments.
- Security vendors will roll out dedicated MLflow and MLOps exposure scanning within their existing cloud security posture management products, following the same playbook used after prior high-profile SSRF incidents.
- Enterprises that treat internal AI tooling as low-risk will keep getting caught out, since this incident shows the pattern isn’t limited to customer-facing applications.
Frequently Asked Questions
What is CVE-2026-64849?
It’s a critical, unauthenticated server-side request forgery flaw in MLflow’s webhook testing endpoint, rated CVSS 9.3, that lets attackers reach cloud metadata services and steal live AWS, GCP, or Azure credentials.
Which MLflow versions are affected?
Every release before 3.15.0. The fix shipped on July 31, 2026, and adds connection-time validation that blocks the redirect-based bypass.
Is this vulnerability actually being exploited?
Yes. CISA added it to the Known Exploited Vulnerabilities catalog on August 19, 2026, a designation reserved for flaws with confirmed real-world exploitation, and multiple researchers have documented incidents involving credential theft, cryptocurrency mining, and new IAM users created for persistence.
Do federal agencies have a deadline to patch it?
Yes. Under CISA’s binding directive, U.S. federal civilian agencies must remediate affected MLflow instances by September 2, 2026. Private organizations aren’t bound by that deadline but face the same real-world risk.
How is this different from the 2019 Capital One breach?
The underlying trick is nearly identical: forge a request to a cloud metadata endpoint and steal the credentials it returns. The difference is the target. Capital One’s attacker abused a misconfigured firewall. This flaw lives in an AI development tool used by thousands of organizations to manage machine learning pipelines.
What should I do if I run a self-hosted MLflow server?
Upgrade to MLflow 3.15.0 or later immediately, rotate any cloud credentials the hosting environment could have exposed, and consider blocking direct network access to 169.254.169.254 for the MLflow process unless it’s explicitly required.
Does MLflow being open source make this worse?
Not inherently, but MLflow’s scale, over 30 million downloads a month according to its own project documentation, means a huge number of self-hosted deployments to track down and patch, unlike a SaaS product where the vendor can push a fix centrally.
Are managed MLflow services on Databricks affected?
The vulnerability applies to self-hosted MLflow tracking servers running versions before 3.15.0. Organizations using a managed offering should confirm patch status directly with their provider rather than assume it based on this reporting.
