CVE-2026-64849

Executive Summary

CVE-2026-64849 describes a critical Server-Side Request Forgery (SSRF) vulnerability affecting MLflow, an open-source AI engineering platform, in versions prior to 3.15.0. This flaw allows unauthenticated attackers to exploit a webhook test endpoint to bypass URL validation, enabling them to make arbitrary requests from the MLflow server to internal networks or cloud metadata services. With a CVSS score of 9.3 (Critical), successful exploitation can lead to significant information disclosure, potentially compromising sensitive internal data.

Technical Analysis

The vulnerability, classified as CWE-918 (Server-Side Request Forgery), resides in the handling of the POST /api/2.0/mlflow/webhooks/{id}/test endpoint within MLflow. This endpoint is designed to test webhook configurations. The core issue stems from an incomplete URL validation mechanism.

Specifically, when a user provides a URL to be tested, the _validate_webhook_url() function in mlflow/utils/validation.py is invoked. However, this validation is performed only on the initial URL provided by the attacker. Subsequently, the mlflow/webhooks/delivery.py module, responsible for actually delivering the webhook, is designed to follow HTTP redirects. Crucially, mlflow/webhooks/delivery.py re-resolves the hostname of the redirected URL without re-applying the initial validation checks or pinning the previously validated address.

This discrepancy creates a window for exploitation. An attacker can supply an initial, seemingly benign URL to the POST /api/2.0/mlflow/webhooks/{id}/test endpoint that successfully passes the _validate_webhook_url() check. This initial URL, however, is configured to immediately issue an HTTP 3xx redirect to an internal, unauthenticated resource (e.g., a cloud metadata service endpoint like http://169.254.169.254 or an internal IP address). Because mlflow/webhooks/delivery.py follows this redirect and re-resolves the hostname without re-validation, the MLflow server unwittingly makes a request to the attacker's true internal target. The vulnerability allows the attacker to receive the response_status and response_body of the redirected request, thereby exfiltrating sensitive information that the MLflow server can access.

The unauthenticated nature of the POST /api/2.0/mlflow/webhooks/{id}/test endpoint significantly broadens the attack surface, allowing any remote attacker to initiate this request without prior authorization.

Exploitation Scenarios

Exploitation of CVE-2026-64849 follows a typical SSRF attack pattern, leveraging the trust relationship between the vulnerable MLflow server and its internal network.

1. Reconnaissance/Target Identification: An attacker identifies an internet-accessible MLflow instance running a version prior to 3.15.0. The primary attack vector is the unauthenticated POST /api/2.0/mlflow/webhooks/{id}/test endpoint. The attacker may also perform OSINT to understand the target's cloud environment (e.g., AWS, Azure, GCP) to tailor specific internal IP targets (like metadata service endpoints).

2. Triggering the Flaw: The attacker crafts a malicious HTTP POST request to the vulnerable endpoint, for example: POST /api/2.0/mlflow/webhooks/{some_id}/test The request body would contain JSON data specifying a webhook configuration, including a url parameter. The critical part is that this url initially points to an attacker-controlled server (e.g., http://attacker-controlled-server.com/redirect). This initial URL is designed to pass the _validate_webhook_url() check.

3. Payload/Execution Method: The attacker-controlled server (e.g., attacker-controlled-server.com/redirect) is configured to immediately respond with an HTTP 302 (Found) or 301 (Moved Permanently) redirect to the actual target URL. This target URL would be an internal resource, such as:

   • A cloud metadata service endpoint (e.g., http://169.254.169.254/latest/meta-data/iam/security-credentials/) to obtain temporary AWS credentials.
   • An internal IP address on the MLflow server's network (e.g., http://192.168.1.100/admin) to enumerate internal services or access administrative interfaces.
   • A localhost endpoint (http://127.0.0.1/) to query services running on the same machine as MLflow. Because mlflow/webhooks/delivery.py follows redirects and re-resolves the hostname without re-validation, the MLflow server's network stack will initiate a request to the internal target specified in the redirect.

4. Post-Exploitation Impact: The MLflow server sends the request to the internal target and, critically, returns the response_status and response_body of that internal request back to the attacker as part of the POST /api/2.0/mlflow/webhooks/{id}/test response. This allows the attacker to exfiltrate sensitive data, such as cloud instance metadata, internal network configuration details, service banners, or even data from internal API endpoints that are not publicly exposed. This information can then be used for further reconnaissance, lateral movement, or privilege escalation within the target's infrastructure.

No public PoC or exploit code is available for this specific CVE; the attack chain is inferred directly from the vulnerability class and the detailed NVD description.

Impact Assessment

The impact of CVE-2026-64849 is severe, as reflected by its CVSSv3.1 score of 9.3 (Critical). The "Server-Side Request Forgery" (SSRF) nature of the vulnerability means that an attacker can coerce the vulnerable MLflow server into making requests to arbitrary internal or external network resources from the server's perspective.

The CVSS vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N highlights the key aspects of its impact:

• Attack Vector: Network (AV:N): The vulnerability can be exploited remotely over the network without any prior access or complex conditions.
• Attack Complexity: Low (AC:L): Exploitation is straightforward, requiring only the ability to send a crafted HTTP POST request and host a simple redirector server.
• Privileges Required: None (PR:N): No authentication or specific privileges are needed, making the vulnerability accessible to any remote attacker.
• User Interaction: None (UI:N): No user interaction is required for successful exploitation.
• Scope: Changed (S:C): A successful attack allows the attacker to operate outside the security scope of the vulnerable component, gaining access to resources (internal networks, cloud metadata services) that are typically protected from external access. This is a significant aspect of SSRF vulnerabilities, enabling access to resources that would otherwise be isolated.
• Confidentiality: High (C:H): This is the most significant impact. Attackers can read highly sensitive information, such as cloud provider IAM credentials (e.g., AWS EC2 instance profiles), API keys, internal network diagrams, sensitive configuration files, or data from internal databases/services. The ability to retrieve response_body directly facilitates this data exfiltration.
• Integrity: Low (I:L): While the primary impact is information disclosure, an attacker might be able to trigger actions on internal services if those services allow state-changing operations via GET/POST requests that the MLflow server can be coerced into sending. However, direct modification of MLflow's own data or system files is not the direct consequence of this SSRF.
• Availability: None (A:N): The vulnerability does not directly impact the availability of the MLflow service or other internal systems.

Business impact can include severe data breaches, unauthorized access to cloud resources, lateral movement within the corporate network, and compliance violations. Organizations running MLflow instances prior to version 3.15.0 are at high risk, especially if these instances reside in environments with access to sensitive internal services or cloud metadata APIs. The blast radius extends to any system or service accessible by the MLflow server's network interface.

Detection Guidance

Sigma Rule

This Sigma rule aims to detect attempts to exploit the unauthenticated POST endpoint by looking for requests that target the specific API path and might contain redirect patterns or internal IP addresses within the URL parameters. Due to the lack of specific payload examples, this rule focuses on the access pattern and potential malicious URL structures.

title: MLflow Unauthenticated SSRF Attempt via Webhook Test Endpoint
id: aabbccdd-1234-5678-9012-efgghhiijjkk
status: experimental
description: Detects unauthenticated POST requests to the MLflow webhook test endpoint,
    potentially indicating an SSRF attempt (CVE-2026-64849). Focuses on unusual URL patterns
    or redirect attempts.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-64849
author: ValterSit Threat Intelligence
date: 2024/01/01
modified: 2024/01/01
logsource:
  category: webserver
  service: mlflow
detection:
  selection_endpoint:
    cs-method: POST
    cs-uri-stem|endswith: '/api/2.0/mlflow/webhooks/test' # Assuming {id} is dynamic, targeting the test endpoint
    # Note: MLflow's NVD description states '/api/2.0/mlflow/webhooks/{id}/test'.
    # Exact URI matching might need adjustment based on specific proxy/web server logs
    # and how {id} is logged. Using `endswith` as a starting point.
  selection_payload_keywords:
    # Look for common SSRF targets or redirect indicators within the request body (URL parameter)
    # These are illustrative, actual payload would be in the URL parameter within the JSON body
    cs-uri-query|contains:
      - 'url=http://169.254.169.254' # AWS metadata service
      - 'url=http://127.0.0.1' # Localhost
      - 'url=http://10.' # Private IP range
      - 'url=http://172.16.' # Private IP range
      - 'url=http://192.168.' # Private IP range
      - 'url=http://[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}/' # Generic IP
    # In reality, the URL parameter is in the JSON request body.
    # More advanced rules would require parsing HTTP POST body, which is
    # difficult in generic web server logs but possible with WAFs or HTTP proxies.
    # This rule might need adaptation depending on log enrichment capabilities.
  condition: selection_endpoint and selection_payload_keywords
falsepositives:
  - Legitimate webhook testing that inadvertently targets internal resources
  - Internal security testing
level: high

YARA Rule

This YARA rule focuses on identifying the specific endpoint within HTTP request logs or network captures. It cannot reliably detect the full SSRF chain due to the dynamic nature of the redirect, but it can flag the initial access to the vulnerable endpoint.

rule CVE_2026_64849_MLflow_SSRF {
  meta:
    author = "ValterSit Threat Intelligence"
    date = "2024-01-01"
    description = "Detects HTTP POST requests targeting the vulnerable MLflow webhook test endpoint (CVE-2026-64849)."
    reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-64849"
    cve = "CVE-2026-64849"
    severity = "High"
  strings:
    $http_post = "POST /api/2.0/mlflow/webhooks/" ascii nocase
    $endpoint_test = "/test HTTP/1." ascii nocase
    $json_url_key = "\"url\":" ascii nocase
    $aws_metadata = "169.254.169.254" ascii
    $localhost = "127.0.0.1" ascii
    $internal_ip_range_1 = "192.168." ascii
    $internal_ip_range_2 = "10." ascii
    $internal_ip_range_3 = "172.16." ascii
    $redirect_header = "Location:" ascii nocase // If inspecting response headers, for the redirector
    $mlflow_header = "MLflow/" ascii nocase // To identify MLflow generated requests in outbound logs

  condition:
    ($http_post and $endpoint_test) and
    (
        // Look for common SSRF targets potentially specified in the 'url' field of the JSON body
        // This requires content inspection for the 'url' key and its value
        ($json_url_key and ($aws_metadata or $localhost or $internal_ip_range_1 or $internal_ip_range_2 or $internal_ip_range_3))
        // More sophisticated detection would involve parsing JSON and URL encoding, which is hard for YARA.
        // This provides a heuristic for common SSRF patterns within a limited context.
    )
}

Suricata IDS Rule

This Suricata rule aims to detect the initial unauthenticated POST request to the vulnerable endpoint. It can also include keywords for common SSRF targets within the request body.

# Rule for CVE-2026-64849 - MLflow Unauthenticated SSRF
# Detects POST requests to the vulnerable webhook test endpoint with potential SSRF targets.
alert http any any -> any any (msg:"CVE-2026-64849 MLflow SSRF Attempt - Webhook Test Endpoint Access"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/api/2.0/mlflow/webhooks/"; fast_pattern; content:"/test"; distance:0; content:"url="; http.request_body; pcre:"/url=(http|https)%3A%2F%2F(169%5C.254%5C.169%5C.254|127%5C.0%5C.0%5C.1|10%5C.[0-9]{1,3}|172%5C.(1[6-9]|2[0-9]|3[0-1])%5C.[0-9]{1,3}|192%5C.168%5C.[0-9]{1,3})/"; nocase; sid:2026648491; rev:1;)

# An additional rule to detect outbound connections from the MLflow server process
# to known cloud metadata service IPs, which might indicate successful SSRF exploitation.
# This requires knowledge of the MLflow server's internal IP.
alert tcp $HOME_NET any -> 169.254.169.254 80 (msg:"CVE-2026-64849 MLflow SSRF - Outbound to AWS Metadata Service"; flow:established,to_server; classtype:attempted-user; sid:2026648492; rev:1;)
alert tcp $HOME_NET any -> 100.100.100.200 80 (msg:"CVE-2026-64849 MLflow SSRF - Outbound to GCP Metadata Service"; flow:established,to_server; classtype:attempted-user; sid:2026648493; rev:1;)

Elastic Detection

This Elastic EQL rule correlates network events (inbound access to the vulnerable endpoint) with potential outbound connections to internal/metadata services from the MLflow host. This requires logging of both web server access and network egress.

sequence by host.id
  [http where http.request.method == "POST" and
             http.request.url.path : "/api/2.0/mlflow/webhooks/*/test" and
             http.request.body.content : "*\"url\":\"http://*" and
             (http.request.body.content : "*169.254.169.254*" or
              http.request.body.content : "*127.0.0.1*" or
              http.request.body.content : "*10.*" or
              http.request.body.content : "*172.16.*" or
              http.request.body.content : "*192.168.*")]
  [network where event.type == "connection" and
               destination.ip in ("169.254.169.254", "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16") and
               process.name : ("python", "mlflow") /* Assuming MLflow runs as python or a specific service */]
until
  [any where host.id != null] /* Reset sequence if no activity */

Splunk SPL Query

This Splunk query looks for HTTP POST requests to the vulnerable endpoint and attempts to identify common SSRF patterns within the request URL or body.

index=weblogs sourcetype=access_combined (method="POST" uri_path="/api/2.0/mlflow/webhooks/*/test")
| fields _time client_ip method uri_path uri_query request_body
| eval is_ssrf_attempt = if(
    match(request_body, "(?i)\"url\":\"http[s]?://(169\.254\.169\.254|127\.0\.0\.1|10\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}|172\.(1[6-9]|2[0-9]|3[0-1])\.[0-9]{1,3}\.[0-9]{1,3}|192\.168\.[0-9]{1,3}\.[0-9]{1,3})"),
    "true", "false"
  )
| where is_ssrf_attempt="true"
| table _time client_ip method uri_path request_body is_ssrf_attempt
| `alert_mlflow_ssrf_webhook_test`

(Note: request_body field availability depends on web server log configuration or proxy logs. The macro ``alert_mlflow_ssrf_webhook_test` would be a custom alert action).

Wazuh OSSEC Rule

This Wazuh rule focuses on detecting the specific HTTP access pattern in web server logs, which is typically the most reliable source for such an event.

<group name="web,attack,mlflow,">
  <rule id="100001" level="10">
    <if_sid>31101</if_sid> <!-- Parent rule for web server 400/500 errors or generic access -->
    <request_method>POST</request_method>
    <url>/api/2.0/mlflow/webhooks/\S+/test</url>
    <description>MLflow: Unauthenticated SSRF attempt via webhook test endpoint (CVE-2026-64849)</description>
    <group>attack,ssrf,</group>
  </rule>

  <rule id="100002" level="12">
    <if_sid>100001</if_sid>
    <decoded_as>json</decoded_as>
    <field name="url" type="pcre2">\b(169\.254\.169\.254|127\.0\.0\.1|10\.\d{1,3}\.\d{1,3}\.\d{1,3}|172\.(1[6-9]|2[0-9]|3[0-1])\.\d{1,3}\.\d{1,3}|192\.168\.\d{1,3}\.\d{1,3})\b</field>
    <description>MLflow: High-confidence SSRF attempt detected targeting internal IP/metadata service.</description>
    <group>attack,ssrf,high_severity,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence for CVE-2026-64849 is 0/4 (UNPATCHED) as no patch evidence from tracked sources has been identified in the provided data, but a vendor fix version is known.

1. Immediate Mitigations:

   • Network Segmentation and Egress Filtering: Implement strict network egress filtering on firewalls or security groups for the MLflow server. Restrict outbound connections from the MLflow host to only essential, known-good external services. Specifically, block all outbound connections to private IP ranges (e.g., 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and cloud metadata service IP addresses (e.g., 169.254.169.254 for AWS) from the MLflow server. This is the most effective immediate mitigation against SSRF.
   • Restrict Access to MLflow: If feasible, limit network access to the MLflow instance to trusted internal networks or specific IP addresses only, especially until a patch can be applied. Placing it behind an authenticated reverse proxy or VPN could also help.
   • Web Application Firewall (WAF) Rules: Deploy WAF rules to detect and block requests to the POST /api/2.0/mlflow/webhooks/{id}/test endpoint that contain internal IP addresses or known metadata service endpoints within the URL parameter in the request body. Note that this requires inspection of the request body and URL decoding.
   • Monitor Outbound Connections: Implement robust logging and monitoring for all outbound network connections initiated by the MLflow server. Alert on any connections to suspicious or unauthorized internal IP ranges or cloud metadata service endpoints.

2. Patch/Upgrade Steps:

   • Upgrade MLflow: The vendor has addressed this vulnerability in version 3.15.0. Organizations should plan to upgrade their MLflow installations to version 3.15.0 or newer as soon as possible. Follow the official MLflow documentation for upgrade procedures to ensure data integrity and compatibility.

3. Long-Term Hardening:

   • Principle of Least Privilege: Ensure the MLflow application runs with the minimum necessary permissions on the host and has restricted network access.
   • Secure Coding Practices: Advocate for and implement secure coding practices, particularly robust and comprehensive URL validation mechanisms that account for redirects and resolve hostnames to their final destination before validation.
   • Regular Security Audits: Conduct periodic security audits and penetration tests of applications, focusing on input validation and external interaction points.
   • Supply Chain Security: Regularly review and update dependencies to ensure that all components are free from known vulnerabilities.

References

• National Vulnerability Database (NVD): https://nvd.nist.gov/vuln/detail/CVE-2026-64849 (Placeholder URL, as CVE is in future)
• MLflow GitHub Repository / Release Notes: Refer to the official MLflow GitHub releases for version 3.15.0, where the fix for this vulnerability would be detailed. (e.g., https://github.com/mlflow/mlflow/releases/tag/v3.15.0 - specific link not available yet).
• CWE-918: Server-Side Request Forgery (SSRF): https://cwe.mitre.org/data/definitions/918.html
• OWASP Server-Side Request Forgery Prevention Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html