CVE-2026-2393: MLflow SSRF Vulnerability in Webhooks

CVE-2026-2393 Overview

CVE-2026-2393 is a Server-Side Request Forgery (SSRF) vulnerability in MLflow versions prior to 3.9.0. The _create_webhook() function in mlflow/server/handlers.py accepts a user-controlled url parameter without validation. The _send_webhook_request() function in mlflow/webhooks/delivery.py then issues HTTP POST requests to that attacker-supplied URL. An authenticated attacker can coerce the MLflow backend into reaching internal services, cloud metadata endpoints, or arbitrary external hosts. The flaw maps to [CWE-918: Server-Side Request Forgery].

Critical Impact
An authenticated attacker can pivot the MLflow server into internal networks and cloud metadata services, enabling credential theft and data exfiltration.

Affected Products

MLflow versions prior to 3.9.0
MLflow tracking server deployments exposing the webhook API
Self-hosted MLflow instances on AWS, Azure, and GCP infrastructure

Discovery Timeline

2026-05-11 - CVE-2026-2393 published to NVD
2026-05-13 - Last updated in NVD database

Technical Details for CVE-2026-2393

Vulnerability Analysis

MLflow exposes a webhook subsystem that lets clients register HTTP endpoints for event notifications. The _create_webhook() handler accepts a url field from the request body and persists it without validating the scheme, host, or destination. When an event fires, _send_webhook_request() reads the stored URL and dispatches an HTTP POST request from the MLflow backend process.

The handler performs no allowlist check, no scheme restriction, and no resolution of the target host against internal address ranges. Any authenticated user with permission to create webhooks can therefore direct the server to any reachable address. The request originates from the MLflow server's network context, bypassing perimeter controls that would block external clients.

Root Cause

The root cause is missing input validation on the webhook URL parameter. The code path trusts user-supplied input as a destination for outbound HTTP traffic. There is no URL parser that enforces https:// schemes, no denylist for loopback or link-local addresses, and no allowlist of approved webhook receivers. This combination produces a textbook SSRF primitive described in [CWE-918].

Attack Vector

An authenticated attacker submits a webhook creation request with a url pointing at an internal target. Common targets include http://169.254.169.254/latest/meta-data/ on AWS for instance metadata, http://metadata.google.internal/ on GCP, or http://localhost: ports hosting unauthenticated admin services. When MLflow triggers webhook delivery, the backend issues the POST request and may return response data or side effects observable to the attacker.

Exploitation requires network reachability to the MLflow API and a valid authenticated session. Refer to the Huntr Bug Bounty Report and the GitHub Commit History for full technical details of the vulnerable code path and the fix.

Detection Methods for CVE-2026-2393

Indicators of Compromise

Webhook records in the MLflow database containing URLs targeting 127.0.0.1, localhost, 169.254.169.254, metadata.google.internal, or RFC1918 ranges
Outbound HTTP requests from the MLflow server process to cloud metadata IPs
Unexpected POST calls originating from the MLflow backend to non-business endpoints

Detection Strategies

Audit the MLflow webhooks table and flag any URL whose host resolves to internal, loopback, or link-local addresses
Inspect MLflow application logs for _send_webhook_request() invocations targeting non-allowlisted destinations
Correlate authenticated MLflow API activity with subsequent outbound connections from the server host

Monitoring Recommendations

Egress filter MLflow server traffic and alert on connections to 169.254.169.254 and other metadata endpoints
Monitor for new webhook registrations from non-administrative accounts
Forward MLflow access logs and host network telemetry to a centralized analytics platform such as Singularity Data Lake for correlation across identity, endpoint, and cloud events

How to Mitigate CVE-2026-2393

Immediate Actions Required

Upgrade MLflow to version 3.9.0 or later on all tracking servers
Review existing webhook entries and remove any pointing to internal hosts or metadata services
Restrict webhook creation privileges to a minimal set of trusted users
On AWS, enforce IMDSv2 to blunt metadata theft via SSRF

Patch Information

The upstream fix is documented in the GitHub Commit History. The patch adds validation on the webhook URL handling in mlflow/server/handlers.py and mlflow/webhooks/delivery.py. Operators should upgrade to MLflow 3.9.0 or later, which contains the validated webhook delivery logic.

Workarounds

Block outbound traffic from the MLflow server to cloud metadata IP ranges and internal management subnets at the network layer
Place the MLflow server behind an egress proxy that enforces a destination allowlist for webhook deliveries
Disable the webhook feature entirely if it is not in use by removing webhook permissions from all user roles

bash

# Configuration example: restrict MLflow egress on Linux via iptables
# Block cloud metadata endpoints from the MLflow server
iptables -A OUTPUT -m owner --uid-owner mlflow -d 169.254.169.254 -j REJECT
iptables -A OUTPUT -m owner --uid-owner mlflow -d 169.254.170.2 -j REJECT

# Require IMDSv2 on AWS EC2 hosts running MLflow
aws ec2 modify-instance-metadata-options \
  --instance-id i-0123456789abcdef0 \
  --http-tokens required \
  --http-endpoint enabled