Loading vulnerability…
CVE-2026-64849 is an unauthenticated full-read server-side request forgery vulnerability in MLflow versions prior to 3.15.0. MLflow validates only the initially supplied webhook URL, while webhook delivery follows HTTP redirects and re-resolves hostnames without pinning the validated destination address. An attacker can bypass URL validation through redirect handling or DNS rebinding and cause the MLflow server to request internal, loopback, link-local, or cloud metadata resources. The webhook test functionality returns the upstream response status and body, making this a read-capable SSRF issue.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos (3 hidden).
This 13-file repository is a Docker-based educational/CTF lab for a claimed MLflow webhook redirect SSRF issue (CVE-2026-64849), using stock MLflow 3.13.0. The primary automated entry point, mlflow-ssrf-lab/exploit.py, uses Python requests to create a webhook through MLflow's REST API and invoke its test action. Its webhook URL points to attacker_server, whose Python HTTP server returns a 302 redirect. The intended vulnerable behavior is that MLflow validates the original webhook URL but follows the redirect to an internal destination without re-validating it, then exposes the final response in the webhook test result. The docker-compose topology creates three services on lab_network: MLflow on host port 5000, an attacker redirect/capture server on host port 8080, and an intentionally host-unpublished internal service. internal_service.py runs simulated targets on ports 8888 and 8889, including administrator secrets, configuration, simulated IMDS credentials, and a hidden final endpoint. These values and flags are deliberately fabricated for the training environment; no malware persistence, shell, command execution, or real credential theft capability is present. Supporting Bash scripts start, reset, diagnose, and interactively demonstrate the lab. ctf_lab.sh provides manual webhook/redirect workflows and validates encoded CTF flags. README.md, EXPLOITATION_GUIDE.md, and REDTEAM_GUIDE.md document the TOCTOU/redirect theory, manual exploitation, and mitigations. The exploit's claim of 'RCE' in its banner is not supported by the code: its actual capability is HTTP SSRF and response-body exfiltration.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
96 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
A high-severity SSRF vulnerability in MLflow's webhook functionality involving a redirect-based validation bypass, enabling unauthenticated access to metadata services via server-side requests.
MLflow vulnerability listed as added to CISA KEV.
Unauthenticated SSRF vulnerability in MLflow's webhook test endpoint that can be exploited via redirect handling to access internal resources such as cloud metadata services and steal cloud credentials.
An SSRF vulnerability in MLflow affecting versions prior to 3.15.0.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.