MLflow: Unauthenticated full-read SSRF in webhook delivery: _validate_webhook_url bypassed via unvalidated HTTP redirects (and DNS rebinding)
Affects MLflow Tracking Server (mlflow server) before 3.15.0 in its default setup with no authentication and the default SQLite backend. The vendor rating is not given. Fixed in 3.15.0.
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Listed in CISA KEV
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Actively exploited
- Fix
- Fixed in 3.15.0
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: active
- Automatable: yes
- Technical impact: partial
Summary
MLflow versions from 3.3.0 up to (but not including) 3.15.0 are affected, where the webhook test feature can be abused without authentication to make the server send requests to internal or cloud metadata services. An attacker could read the responses returned, such as status codes and body contents, exposing sensitive internal information.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
MLflow is an open source AI engineering platform for agents, large language models, and machine learning models. Starting in 3.3.0 and prior to 3.15.0, the unauthenticated POST /api/2.0/mlflow/webhooks/{id}/test endpoint calls _validate_webhook_url() in mlflow/utils/validation.py only for the original URL while mlflow/webhooks/delivery.py follows redirects and re-resolves the hostname without pinning the validated address, allowing attackers to reach internal or cloud metadata services and receive response_status and response_body. This issue is fixed in version 3.15.0.
Timeline
- CVE published
- Added to CISA KEV
CISA has evidence of exploitation in the wild
- CISA SSVC assessment
Exploitation: active · Automatable: yes · Technical impact: partial
- CISA remediation deadline
Due date for US federal agencies to patch
- Record last updated
- EPSS reached 10%
FIRST estimates at least a 10% chance of exploitation in the next 30 days
Affected versions
- mlflow mlflow
From 3.3.0 · fixed in 3.15.0
- mlflowBitnami
From 3.3.0 · fixed in 3.15.0
- mlflowPyPI
From 3.3.0 · fixed in 3.15.0
- mlflowPyPI
fixed in 3.15.0
References 5
Questions about CVE-2026-64849
What does this mean?
The server's check on webhook URLs can be bypassed through HTTP redirects and DNS rebinding. An unauthenticated caller can then make the server send requests to internal, loopback, or cloud-metadata addresses and read the responses, which can expose items such as AWS IMDS IAM credentials.Source: github.com
Am I affected, and how do I check?
Affected builds are MLflow versions before 3.15.0 that expose the model-registry webhooks API without authentication, such as the default mlflow server with the default SQLite backend. Check the installed version with mlflow --version. The product data lists the range starting at 3.3.0, while the advisory text starts it at 3.10.0.Source: github.com
What should I do about it?
Upgrade MLflow to 3.15.0 or later, which is the listed fixed version.Source: github.com
Is it being exploited?
Yes. CISA added it to its Known Exploited Vulnerabilities catalog on 2026-08-19, which means it has evidence of attacks. No public exploit code is tracked.Source: cisa.gov, cve.now feed data