A critical, unauthenticated server-side request forgery vulnerability in MLflow — the open-source machine learning lifecycle platform used across MLOps pipelines to track experiments and serve a model registry — is being actively exploited in the wild. Tracked as CVE-2026-64849 (CVSS 3.1: 9.3), the flaw affects every MLflow version prior to 3.15.0. According to watchTowr’s Attacker Eye honeypot network, opportunistic scanning against internet-facing MLflow servers began within hours of the CVE being assigned, with attackers going straight for cloud instance metadata to harvest credentials.

What happened

MLflow’s model registry ships a webhook feature that lets administrators configure callback URLs to be notified of registry events. To let admins verify a webhook works before relying on it, MLflow exposes POST /api/2.0/mlflow/webhooks/{id}/test — an endpoint that triggers an immediate delivery attempt and reflects the upstream server’s response status and body back to the caller. On a default MLflow Tracking Server deployment, this endpoint requires no authentication at all.

MLflow already had an SSRF guard for this feature, added upstream in PR #20747, which validates the webhook URL before allowing delivery to prevent requests to internal or link-local addresses. The guard has a straightforward bypass: it checks only the original, attacker-supplied URL. The actual delivery logic follows HTTP redirects and re-resolves hostnames at request time without pinning the address that was validated — a classic time-of-check/time-of-use gap. An attacker registers a webhook pointing at a public HTTPS endpoint they control, which passes the SSRF guard cleanly, then has that endpoint respond with a 302 redirect to an internal target such as http://169.254.169.254/latest/meta-data/iam/security-credentials/. MLflow’s delivery logic follows the redirect, fetches the response from the cloud metadata service, and returns the full body — including any temporary IAM credentials — straight to the unauthenticated caller. DNS rebinding provides an equivalent bypass path for cases where redirect-following is restricted.

The result is an unauthenticated, full-read SSRF primitive against any exposed MLflow Tracking Server: no login, no API key, one HTTP request.

Technical details

  • CVE-2026-64849 — MLflow, unauthenticated SSRF in webhook test delivery via unvalidated HTTP redirects (GHSA-7gwp-5pfp-969j).
  • CVSS 3.1: 9.3 (network, no authentication, no user interaction, high confidentiality impact).
  • Affected: All MLflow versions prior to 3.15.0.
  • Root cause: _validate_webhook_url() validates only the initially supplied URL; the delivery path follows redirects and re-resolves hostnames without re-checking or pinning the previously validated address.
  • Vulnerable endpoint: POST /api/2.0/mlflow/webhooks/{id}/test — unauthenticated by default, reflects the full upstream response (status + body) to the requester.
  • Fixed version: MLflow 3.15.0.
  • Disclosure timeline: Reported privately by researcher freeman-bb on June 12, 2026; independently rediscovered via code review and disclosed by AUTHENSOR on June 26, 2026; CVE publicly assigned August 17, 2026.

Impact

Any organization running an internet-reachable MLflow Tracking Server — a common pattern for teams running MLOps infrastructure on EC2, GKE, or similar — is exposed to unauthenticated, remote credential theft. Because the endpoint returns the full response body from the redirected request, it works equally well against AWS/GCP/Azure instance metadata services, internal admin panels, and any other service reachable from the MLflow host’s network position. Stolen IAM credentials from a cloud metadata endpoint typically carry whatever permissions were attached to the instance role — in ML infrastructure, that’s frequently broad read/write access to S3 buckets holding training data and model artifacts, or permissions to spin up additional compute.

watchTowr’s honeypot telemetry shows attackers scanning for and hitting this endpoint within hours of the CVE going public, aiming directly at metadata endpoints rather than probing broadly first — indicating either automated exploit tooling built the moment the advisory dropped, or the bug was already known and weaponized in the wild before public disclosure. Given the low barrier (a single unauthenticated POST request) and the high value of the target (cloud credentials), this is squarely in the category of vulnerabilities that get mass-exploited fast.

Mitigation

  • Upgrade to MLflow 3.15.0 or later immediately — this is the only complete fix.
  • Inventory all MLflow deployments, including development, experimentation, and “shadow” MLOps instances that security teams may not know about — these are exactly the servers most likely to be internet-facing with no additional auth layer.
  • Never expose MLflow Tracking Servers directly to the internet. Put them behind a VPN, reverse proxy with authentication, or private network segment regardless of patch status — MLflow’s built-in auth story is thin, and this class of bug (unauthenticated internal endpoint) tends to recur.
  • Block or restrict outbound access to cloud metadata endpoints (169.254.169.254 and equivalents) from hosts running MLflow, or require IMDSv2/token-bound metadata access where the cloud provider supports it, so a successful SSRF can’t be turned directly into usable credentials.
  • Rotate IAM credentials for any instance role attached to an MLflow host that was internet-reachable prior to patching, and audit CloudTrail/equivalent logs for anomalous API activity from those credentials.
  • Review webhook configurations on any MLflow registry for entries the team didn’t create — a redirect-based exploit requires registering or testing a webhook, which may leave an audit trail.

Sources: The Hacker News — Attackers Exploit MLflow SSRF Flaw, GitHub Advisory GHSA-7gwp-5pfp-969j, Decipher — MLflow Bug Actively Exploited to Steal Credentials, IONIX — CVE-2026-64849 Threat Center.