A critical vulnerability in MLflow, the widely used open-source platform for tracking and deploying machine learning models, is already being actively exploited just hours after details became public. Tracked as CVE-2026-64849 and rated 9.3 on the CVSS scale, the flaw allows unauthenticated attackers to weaponize a webhook-testing feature into a direct path toward stealing cloud credentials.

A Full-Read Primitive, Not Just Blind SSRF

The root of the problem is architectural as much as it is a coding bug. MLflow’s default Tracking Server, commonly deployed with a local SQLite backend, runs without mandatory authentication out of the box — meaning its model-registry webhooks API can be reachable by anyone who can send it traffic. The specific flaw lives in the unauthenticated POST /api/2.0/mlflow/webhooks/{id}/test endpoint.

Most server-side request forgery bugs are “blind” — an attacker can make the server send a request somewhere, but can’t see the response. This one is different. Instead of simply confirming a webhook fired, the endpoint reflects the complete upstream HTTP status code and response body back to the requester. That transforms a routine SSRF bug into what researchers describe as a full-read primitive: attackers don’t just get to poke internal systems, they get to read exactly what those systems say back.

How the Existing Protections Get Bypassed

MLflow’s maintainers weren’t blind to SSRF risk — version 3.10.0 introduced a _validate_webhook_url() check specifically to block requests aimed at private IP ranges and cloud metadata addresses. The problem is that this validation only inspects the initial destination URL. According to researchers, the delivery handler in mlflow/webhooks/delivery.py follows HTTP redirects without re-validating where the request ultimately lands.

That gap opens two practical bypass paths. An attacker can register a public-facing endpoint that passes the initial allowlist check, then have that endpoint issue an HTTP redirect toward a link-local metadata address or a loopback interface — sailing straight past the original filter. Alternatively, DNS-rebinding techniques can be used to change what a hostname resolves to after the validation step has already approved it, achieving the same result.

Exploitation Moved Fast

According to WatchTowr Intel, whose “Attacker Eye” honeypot network monitors for real-world exploitation of newly disclosed flaws, automated scanning traffic targeting exposed MLflow instances began within hours of the CVE being assigned — well before many organizations would typically have had a chance to patch. The primary targets are MLflow deployments running on AWS, Azure, and Google Cloud, where the reflected-response behavior lets attackers query the well-known link-local metadata address 169.254.169.254 and extract:

• Temporary IAM role credentials tied to the hosting instance
• OAuth tokens issued to the environment
• Broader environment configuration details

Beyond cloud metadata theft, the same technique can reach internal microservices and administrative consoles on loopback interfaces that implicitly trust connections originating from the host itself — effectively using the MLflow server as a pivot point into infrastructure that was never meant to be internet-facing.

Why Patching Alone Isn’t Enough

MLflow 3.15.0 fixes both the redirect-following behavior and the DNS-rebinding exposure, closing the gap that let attackers route around the original destination check. But the project’s advisory carries an important caveat: upgrading does not retroactively revoke any credentials that were already exfiltrated during the window an instance was exposed. Organizations that had an internet-reachable MLflow server running an affected version need to assume compromise of associated cloud credentials, not just patch and move on.

Recommended Actions

• Upgrade all MLflow deployments to version 3.15.0 or later immediately
• Audit access and application logs for any historical requests to /webhooks/*/test endpoints
• Rotate all cloud IAM keys, role credentials, and API secrets associated with hosts running MLflow, regardless of whether exploitation is confirmed
• Apply network egress filtering to block outbound requests from application hosts to link-local metadata addresses
• Place MLflow tracking servers behind an identity-aware proxy or VPN rather than exposing them directly to the public internet

The episode is a reminder that MLOps tooling, often deployed quickly by data science teams outside traditional security review, can carry the same class of high-severity risk as any other internet-facing production service — particularly when it runs with cloud-level privileges by default.