CVE-2026-64849: MLflow: Unauthenticated full-read SSRF in webhook delivery: _validate_webhook_url bypassed via unvalidated HTTP redirects (and DNS rebinding)
MLflow is an open source AI engineering platform for agents, large language models, and machine learning models. 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.
Security readout for executives and security teams
Plain-English summary
Attackers can make a vulnerable MLflow server request protected internal or cloud metadata addresses and return the response to them. No authentication or user interaction is required. This could expose sensitive internal information and enable limited downstream modification, depending on accessible services.
Executive priority
Treat as an immediate remediation priority. CISA lists the vulnerability as known exploited, and vulnerable systems may disclose sensitive internal responses without authentication. Prioritize internet-accessible and cloud-hosted MLflow deployments, then validate logs and outbound activity for possible abuse.
Technical view
Before MLflow 3.15.0, the webhook test endpoint validates only the initial destination. Webhook delivery then follows redirects and performs fresh DNS resolution without pinning the approved address. An attacker can therefore bypass URL validation, reach internal services, and retrieve the resulting HTTP status and body.
Likely exposure
MLflow versions earlier than 3.15.0 are affected. Risk is highest where the webhook test API is reachable by untrusted users and the MLflow host can access internal networks or cloud metadata services. The supplied sources do not establish which specific deployments are exposed.
Exploitation context
CISA KEV inclusion supports known exploitation in the wild. The supplied evidence does not describe campaign scope, targeted organizations, exploit availability, or observed compromise indicators. Exploitation requires network access to the vulnerable MLflow endpoint but requires neither authentication nor user interaction.
Researcher notes
This is CWE-918 SSRF with response disclosure. The trust decision is not preserved across HTTP redirects or subsequent DNS resolution. CVSS 3.1 is 9.3 with network access, low complexity, no privileges, no interaction, changed scope, high confidentiality impact, and low integrity impact. Version 3.15.0 contains the fix.
Mitigation direction
Upgrade MLflow to version 3.15.0 or later immediately.
Until upgraded, restrict MLflow API access to trusted networks and authenticated access layers.
Limit MLflow server egress to required destinations where operationally feasible.
Prevent workload access to cloud metadata services unless explicitly required.
Check current MLflow and CISA guidance for additional mitigations or updates.
Validation and detection
Inventory every MLflow deployment and record its running version.
Confirm whether the webhook test endpoint is reachable from untrusted networks.
Review request logs for unusual webhook test activity.
Review outbound traffic for requests to internal or cloud metadata addresses.
After upgrading, verify every instance reports version 3.15.0 or later.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · medium confidence lookup
CWE-918: Information exposure and cloud metadata lookup
Information exposure and SSRF weaknesses can make discovery, cloud metadata, and credential material review relevant. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
The CVE wording references SSRF or metadata access, so cloud discovery and credential material review may help. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-918 · source CWE mapping
Server-Side Request Forgery (SSRF)
Server-Side Request Forgery (SSRF) represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.