Do Son 
TL;DR
A default MLflow tracking server can be turned into a proxy for reading internal services. Tracked as CVE-2026-64849, the flaw is an unauthenticated full-read SSRF in MLflow’s webhook feature. Full technical details and a proof-of-concept exploit are now public. The maintainers fixed it in MLflow 3.15.0.
- CVE: CVE-2026-64849
- CVSS: 9.3 (Critical · CVSSv3)
- Product: mlflow (pip)
- Affected: < 3.15.0
- Impact: MLflow: Unauthenticated full-read SSRF in webhook delivery: _validate_webhook_url bypassed via unvalidated HTTP redirects (and DNS rebinding)
- Status: Exploited in the wild
- Patched in: 3.15.0
- EPSS: 0.3% (30-day)
- Action: Update to 3.15.0 now
Why It Matters
MLflow is a widely used open-source platform for machine-learning workflows. The default tracking server runs without authentication. As a result, anyone who can reach it can abuse this unauthenticated full-read SSRF.
The payoff for an attacker is high. The server can be made to read cloud instance-metadata, such as AWS IMDS credentials. It can also reach internal-only admin services and scan private hosts.
Reported Exploitation Activity
The urgency grew after disclosure. Security firm watchTowr reports that it observed exploitation attempts against this MLflow flaw. Notably, the firm points to probing that follows the public proof-of-concept.
Treat this as attempted exploitation, not confirmed mass compromise. watchTowr often sees attackers first scan to find exposed, vulnerable servers. Even so, exposed MLflow instances now face active interest. The CVE carries a critical CVSS score of 9.3.
How the Attack Works
MLflow added an SSRF guard in an earlier release. That guard resolves the webhook hostname and blocks private IPs. However, the fix was incomplete.
The delivery code follows HTTP redirects and never pins the validated IP. An attacker hosts a public HTTPS endpoint that passes the check. That endpoint then returns a redirect to an internal or metadata address.
MLflow follows the redirect and never re-validates the new target. Because the webhook test endpoint reflects the response body, the attacker reads the internal reply. The official MLflow security advisory describes the redirect bypass and a DNS-rebinding variant. This report omits any working exploit code.
Read and Write Variants
A 302 redirect gives the full-read primitive through the reflected response. Redirects that preserve the method, such as 307 or 308, enable a blind write. That write path could hit internal endpoints that act on POST requests. Neither variant needs authentication on a default server.
Affected Versions
The flaw affects all MLflow versions before 3.15.0. Exploitation requires the webhook feature, which needs a SQL store. The default server, which uses SQLite, meets that condition.
Researchers confirmed the issue on the then-latest release and on the development branch. It is not a duplicate of the earlier browser-side rebinding CSRF issue.
Patch and Mitigation Steps
Upgrade to MLflow 3.15.0 or later without delay. The fix validates the peer IP right after each connection, including every redirect hop. That change closes both the read and write variants.
Until you patch, never expose the MLflow server to untrusted networks. Restrict access with a VPC, an IP allowlist, or an authentication proxy. You should also enable MLflow’s optional auth plugin where possible. With a public PoC and reported exploitation attempts, patching is now urgent.
Support Our Threat Intelligence
If you find our CVE report and cybersecurity news helpful, consider supporting our work.
Buy Me a Coffee
PayPal
