CVE-2026-2393

What it actually does

MLflow versions before 3.9.0 allow an authenticated user to create a webhook with an arbitrary, user-controlled URL. When webhook delivery is triggered, the MLflow backend sends an HTTP POST request to that URL without adequate validation, scheme restriction, or allowlist enforcement. This creates a server-side request forgery condition that can make the MLflow server reach internal-only services, loopback interfaces, cloud metadata endpoints, or attacker-controlled external infrastructure. Depending on network placement and cloud configuration, this can expose sensitive response data, leak webhook payloads, interact with internal APIs, or assist in cloud credential theft and data exfiltration.

Why it matters to the business

An attacker with MLflow access could use the MLflow server as a pivot point into systems that are not normally reachable from the internet or from the attacker’s workstation. The most serious outcomes include theft of cloud credentials, exposure of internal service data, unauthorized interaction with internal APIs, and leakage of experiment, model, run, or registry metadata included in webhook payloads. Although this issue is not currently listed in CISA KEV and has a low EPSS score, MLflow is commonly deployed near sensitive machine-learning assets and cloud credentials, so exposed or broadly accessible deployments should be prioritized for upgrade.

How an attack unfolds

An attacker first obtains valid MLflow credentials or access to an MLflow deployment where webhook creation is permitted. The attacker submits a webhook configuration whose URL points to a target they want the MLflow server to contact, such as a cloud metadata service, a loopback address, an RFC1918 internal host, an internal admin API, or an attacker-controlled collection server. When a matching MLflow event occurs, the backend webhook delivery code sends an HTTP POST request from the MLflow server to the supplied URL. Because the request originates from the trusted MLflow backend, it may bypass network controls that would block the attacker directly. The attacker can then observe data delivered to their server, trigger side effects on internal HTTP services, or attempt to retrieve credentials or sensitive metadata from infrastructure endpoints, depending on the target service behavior and network permissions.

How to fix it

Upgrade MLflow to version 3.9.0 or later. If immediate upgrade is not possible, disable webhook creation or restrict webhook administration to highly trusted users only. Enforce outbound egress controls from MLflow servers so they cannot connect to cloud metadata endpoints, loopback ranges, link-local addresses, RFC1918 private ranges, Kubernetes service networks, or unapproved external destinations. Block access from MLflow hosts to metadata services such as 169.254.169.254, metadata.google.internal, and cloud-provider-specific credential endpoints unless explicitly required. Where webhooks are needed, enforce a strict allowlist of approved HTTPS destinations, reject non-HTTP(S) schemes, reject redirects to disallowed destinations, and validate DNS resolution to prevent private, loopback, link-local, and rebinding targets. Rotate cloud or service credentials if logs indicate requests to metadata or credential-bearing internal services may have succeeded.

How to confirm the fix worked

Confirm all MLflow servers, containers, and packages report version 3.9.0 or later. Review dependency manifests, container images, running process metadata, and deployment automation to ensure older MLflow versions are not still present. Attempt to create a webhook using a safe test URL that resolves to loopback, link-local, RFC1918 private space, and an unapproved external domain; fixed or mitigated deployments should reject these destinations or prevent delivery. Verify MLflow hosts cannot establish outbound connections to cloud metadata endpoints and internal address ranges that are not explicitly approved. Review existing webhook configurations and remove or disable any destination that is not part of an approved allowlist.

Typical attack path

1. Gain authenticated access to an affected MLflow deployment or compromise an account with permission to create webhooks.
2. Create a webhook with a malicious URL pointing to an internal service, cloud metadata endpoint, loopback address, private IP address, or attacker-controlled external server.
3. Trigger the MLflow event associated with the webhook, such as an experiment, run, model, or registry event, depending on the configured webhook type.
4. Cause the MLflow backend to send an HTTP POST request to the attacker-supplied URL.
5. Use the MLflow server’s network position to reach otherwise inaccessible services, capture webhook payloads, or attempt credential and data exfiltration.
6. Repeat with different target URLs, ports, paths, or internal hostnames to map reachable services and identify sensitive targets.

How to detect it

Review MLflow application, API gateway, reverse proxy, and access logs for webhook creation or update requests containing URLs that point to loopback, link-local, private IP ranges, cloud metadata endpoints, nonstandard ports, or domains not approved for webhook delivery. Inspect stored MLflow webhook configurations for suspicious destinations and recent changes. Correlate webhook creation timestamps with outbound network telemetry from the MLflow server, including firewall logs, VPC flow logs, DNS resolver logs, proxy logs, and EDR network events. Focus on outbound HTTP or HTTPS requests from MLflow processes to 127.0.0.0/8, 169.254.0.0/16, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, Kubernetes service CIDRs, internal hostnames, and cloud metadata services. Look for failed webhook delivery errors, connection refused messages, unusual HTTP status codes, or repeated probing of multiple internal hosts and ports. If cloud metadata access is suspected, review cloud audit logs for unusual use of temporary credentials, unexpected role activity, anomalous API calls shortly after MLflow webhook events, or access from unfamiliar source networks. There are no named threat actors or known KEV exploitation campaigns associated with this issue at this time, so detection should emphasize behavioral evidence of SSRF attempts and post-exploitation credential use.

• 169.254.169.254
• 169.254.169.254/latest/meta-data
• 169.254.169.254/latest/api/token
• metadata.google.internal
• metadata.google.internal/computeMetadata/v1
• 100.100.100.200
• 169.254.170.2
• 127.0.0.1
• localhost
• 0.0.0.0
• [::1]
• /mlflow/webhooks
• mlflow/webhooks/create
• mlflow/server/handlers.py
• mlflow/webhooks/delivery.py
• _create_webhook
• _send_webhook_request
• url=http://169.254.169.254
• url=http://127.0.0.1
• url=http://localhost
• url=http://metadata.google.internal
• url=http://100.100.100.200
• url=http://169.254.170.2
• http://10.
• http://172.16.
• http://172.17.
• http://172.18.
• http://172.19.
• http://172.20.
• http://172.21.
• http://172.22.
• http://172.23.
• http://172.24.
• http://172.25.
• http://172.26.
• http://172.27.
• http://172.28.
• http://172.29.
• http://172.30.
• http://172.31.
• http://192.168.

What your security team should do

• Prioritize upgrade of all MLflow deployments to version 3.9.0 or later, especially internet-facing, shared, or cloud-hosted instances.
• Inventory existing MLflow webhook configurations and immediately remove destinations using private IPs, loopback, link-local addresses, cloud metadata hostnames, unusual ports, or unapproved domains.
• Restrict webhook creation and modification to trusted administrators until all instances are upgraded and egress controls are verified.
• Apply network egress filtering from MLflow servers to block metadata endpoints, internal management networks, Kubernetes service ranges, and arbitrary external destinations.
• Search historical MLflow, proxy, DNS, firewall, and cloud logs for suspicious webhook creation events and outbound requests from MLflow servers to sensitive internal or metadata addresses.
• If metadata endpoint access or credential exposure is suspected, rotate affected cloud instance roles, access keys, API tokens, and service credentials.
• Add continuous monitoring for webhook destination changes and outbound connections from MLflow processes to unexpected IP ranges or ports.