By ByteBot
CVE-2026-64849 was assigned on August 17. Within hours, watchTowr’s global honeypot network detected active exploitation attempts against cloud-hosted MLflow deployments. No authentication required. No user interaction needed. The attacker sends a single POST request and gets cloud credentials back.
If your MLflow Tracking Server is reachable from the internet and running any version below 3.15.0, you have a problem that is actively being probed right now.
What the Flaw Actually Does
The vulnerable endpoint is POST /api/2.0/mlflow/webhooks/{id}/test. On a default MLflow installation, this endpoint is exposed without any authentication. Its job is to test a registered webhook by firing it and returning the response body — which is exactly what makes it dangerous.
The root cause is a time-of-check to time-of-use (TOCTOU) bug. MLflow validates the webhook URL at registration time, confirming it resolves to a public IP. But when the webhook is triggered, the delivery code follows HTTP redirects without re-pinning the originally validated address. An attacker registers a webhook pointing to a public server they control — that server passes validation, then returns an HTTP 302 redirect to 169.254.169.254, the cloud instance metadata endpoint. MLflow follows the redirect, fetches the response, and reflects the full body back to the attacker. DNS rebinding works here too, for the same reason.
The GitHub Security Advisory (GHSA-7gwp-5pfp-969j) assigns this a CVSS score of 9.3. The combination of no authentication required, network-accessible, and full response body reflected earns that rating.
What Attackers Are Walking Away With
The metadata service at 169.254.169.254 is the skeleton key for cloud environments. On AWS, a request to /latest/meta-data/iam/security-credentials/ returns a temporary IAM access key ID, secret access key, and session token — valid until the role refreshes. On GCP, the metadata server hands out service account OAuth tokens. On Azure, Managed Identity tokens. All from a single unauthenticated HTTP request through a misconfigured MLflow instance.
What attackers do with stolen IAM credentials depends on what the MLflow compute role can reach. In many ML pipelines, the tracking server runs with permissions to read S3 buckets containing training data and model artifacts. That is a starting point, not a ceiling. Lateral movement to other AWS services is straightforward once you hold valid credentials, and misconfigured roles can enable full account takeover.
The scanning watchTowr observed is indiscriminate — automated tools sweeping the internet for any exposed MLflow instance. Development and staging environments, the ones most likely to skip authentication and network controls, are the easiest targets. MLflow sees 30 million monthly downloads and runs inside pipelines at thousands of organizations. That is a large target pool for opportunistic attackers.
Check Your Version and Patch
The fix is in MLflow 3.15.0, which pins the validated IP address at connection time, closing the TOCTOU window. Check your version and upgrade:
pip show mlflow | grep Version
pip install --upgrade mlflowIf you are running MLflow in Docker or Kubernetes, update the image tag to 3.15.0 or later and redeploy. If an immediate upgrade is not possible, two mitigations reduce exposure significantly:
- Enable authentication on the MLflow Tracking Server. The webhook test endpoint requires no auth by default, but enabling built-in basic auth blocks unauthenticated callers from reaching it.
- Network-isolate the tracking server. MLflow should never be directly reachable from the public internet. Put it behind a VPN, private subnet, or authenticated reverse proxy.
On AWS, enforce IMDSv2 on any instance running MLflow. IMDSv2 requires a PUT-based session token with a hop limit of 1, which breaks the redirect-based SSRF path to the metadata service. This is not a fix for the MLflow flaw, but it eliminates the most dangerous exploit outcome — credential theft. Check your instance metadata options in the EC2 console or run aws ec2 describe-instances --query 'Reservations[].Instances[].MetadataOptions'.
A Familiar Attack Surface
This is not MLflow’s first SSRF. CVE-2024-37060 was an SSRF through artifact download handling. CVE-2024-27132 was a path traversal. The pattern is consistent: MLflow’s design involves trusting URLs provided by users for webhooks and artifact storage, and that trust keeps getting exploited.
As MLflow has grown from an experiment tracker into a full agentic AI platform — shipping an MCP Registry, LLM judges, and multi-provider integrations — the attack surface has expanded with it. Security reviews of ML infrastructure are not keeping pace with deployment speed. If your team spun up a MLflow instance for a project a few quarters ago and moved on, go check whether it is still running and who can reach it. The active exploitation reports suggest attackers are doing that audit for you.
