MLflow lands on the CISA KEV list after an SSRF that reads your cloud metadata
On August 19, 2026, CISA added CVE-2026-64849, an unauthenticated SSRF in MLflow, to its Known Exploited Vulnerabilities catalog. Any exposed MLflow tracking server should move to 3.15.0 and drop unused webhooks before the September 2, 2026 deadline.
August 19, 2026. CVSS 9.3. Actively exploited. CISA has added CVE-2026-64849 to its KEV catalog of known exploited vulnerabilities, with a remediation deadline of September 2, 2026. The target is not a firewall or a VPN, but MLflow, the open-source platform that acts as the model registry and tracking server for teams shipping LLMs and agents to production. The flaw is an unauthenticated SSRF: a single request is enough to read the cloud metadata of the infrastructure hosting the server.
An SSRF in the webhook test endpoint
MLflow exposes a webhooks endpoint that fires notifications when a model or registry changes state — handy for wiring up a CI/CD pipeline or an alert channel. The problem sits in the POST /api/2.0/mlflow/webhooks/{id}/test route, which lets you test a webhook by sending a request to the configured URL. That route is reachable without authentication.
URL validation exists, but it is incomplete. The _validate_webhook_url() function in mlflow/utils/validation.py only checks the original URL supplied by the caller. The delivery code in mlflow/webhooks/delivery.py, however, follows redirects and re-resolves the hostname without re-pinning the validated address. The result: an attacker submits an outwardly benign public URL that redirects to an internal address — 127.0.0.1, an admin service, or the cloud metadata endpoint 169.254.169.254.
This is not a blind SSRF. The endpoint returns the response body (response_body) and status code (response_status) to the client, so the attacker reads whatever the target reads. That detail is what drives the score to 9.3: full confidentiality (C:H), low complexity, no privileges, no interaction.
Why it matters: the path to your credentials
The most expensive consequence boils down to a single IP address: 169.254.169.254. That is the Instance Metadata Service (IMDS) on AWS — and its equivalents on GCP, Azure, and other clouds. When queried from inside a machine, the IMDS returns the temporary IAM role credentials attached to the instance, without authentication if IMDSv1 is still enabled.
An SSRF that reaches the IMDS therefore turns a simple webhook read into cloud credential theft. If the MLflow server runs on an instance with a broad role — typically the role that reads S3, writes to the registry, and orchestrates training jobs — the attacker gets enough to pivot across the account. The changed scope in the CVSS vector (S:C) says exactly that: the compromise leaves the machine and reaches another layer.
The pattern is not new — it drove the Capital One breach and many others — but it has found fresh ground here: MLOps infrastructure, which concentrates models, data, and secrets, is historically less hardened than the web servers it feeds.
The KEV signal: this is no longer theoretical
KEV listing is not a routine alert. CISA only adds flaws that are actually being exploited, with evidence of exploitation and meaningful impact. CVE-2026-64849 is now on it, which means actors have already automated the chain: scanning the internet for exposed MLflow servers, then hitting the webhook test endpoint to read metadata.
The September 2, 2026 deadline matches the date set by CISA’s Binding Operational Directive (BOD 22-01) for US federal agencies. For the private sector it is advisory — but the logic holds: an actively exploited, readable (not blind), unauthenticated flaw is not something you triage over a week.
MLflow, the silent backbone of MLOps
To grasp the exposure, place MLflow correctly. It is one of the most widely deployed open-source tools in the MLOps lifecycle: it tracks experiments, versions models, and acts as the central registry. Teams shipping agents and LLMs wire it to LangChain, Dagster, Kubeflow, or their own pipelines.
The problem is structural. An MLflow server is often deployed as an internal service that is nevertheless exposed for convenience — so remote notebooks and pipelines can reach it, sometimes directly on the internet with no authentication or firewall. That is exactly the profile exploitation scanners hunt: a secret-rich surface with none of the hardening reflexes that already protect classic web apps.
What to do, in order
The fix ships in 3.15.0. Upgrading is the minimum action, but it is not enough if the exposure remains. Here is the order of operations:
- Upgrade MLflow to 3.15.0 or later across every environment (dev, staging, prod);
- Disable or remove webhooks if you do not use them, and otherwise restrict the test endpoint to internal networks;
- Close network access to the tracking server: no direct internet exposure, always behind an authenticated reverse proxy;
- Enable IMDSv2 (and the equivalent on your cloud) to require a session token before any metadata read;
- Shrink the IAM role of the instance hosting MLflow to the bare minimum.
# Check the deployed version, then upgrade
pip show mlflow | grep -i version
pip install --upgrade "mlflow>=3.15.0"
# On AWS: verify IMDSv2 is required (HttpTokens=required)
aws ec2 describe-instances --instance-id i-0123456789abcdef0 \
--query "Reservations[].Instances[].MetadataOptions"The upgrade fixes the flaw; segmentation limits what the next flaw can reach. Both are necessary, because an MLOps platform is by definition a crossroads of secrets — models, data, cloud credentials.
Verdict
Treat CVE-2026-64849 as an incident, not a routine upgrade. Move to MLflow 3.15.0 now, then confirm that no tracking server is reachable from the internet and that IMDSv2 is enforced on the instances hosting it. If you cannot patch within the day, cut network access to the service immediately: a readable SSRF reaching the IMDS is a keystone into your cloud account, not a cosmetic bug.
The broader signal: CISA has started adding AI infrastructure flaws to the KEV list. MLflow today, other tools in the stack tomorrow. MLOps is joining the critical security perimeter — and it is arriving without the hardening reflexes that already protect your web servers.