CVE-2026-64849: MLflow Server-Side Request Forgery Vulnerability

CVE-2026-64849 is a server-side request forgery (SSRF) vulnerability in MLflow. In plain terms, a flawed request-handling path can let an attacker coerce the MLflow service into making HTTP requests to destinations the attacker chooses, including internal network addresses and cloud instance metadata endpoints, and can return response status and body content to the attacker. That matters because MLflow often runs in data-science and MLOps environments with reach into private networks, object storage, and cloud control planes; SSRF of this class is a common stepping stone to credential theft, lateral movement, and further compromise. Confirm affected builds, fixed releases, and exact attack preconditions only against the vendor advisory.

CISA’s required action emphasizes applying mitigations per vendor instructions, aligning with BOD 26-04 risk-based update prioritization and forensics triage expectations, evaluating internet exposure, and discontinuing use if mitigations are unavailable. Known ransomware use is not documented for this CVE.

How it works

This issue is classified as CWE-918 (Server-Side Request Forgery). SSRF occurs when an application accepts a user-influenced URL or similar locator and the server fetches it without sufficient restriction on scheme, host, port, or network scope. An attacker who can trigger the vulnerable MLflow functionality may cause the server process to request internal hosts, link-local addresses, or cloud metadata services that are unreachable from the public internet but reachable from the MLflow host. Per the available summary, successful abuse can yield response_status and response_body back to the attacker, which may include sensitive configuration or short-lived credentials if metadata or internal admin interfaces respond. Exact entry points, authentication requirements, and request shapes are not specified here; treat any MLflow feature that initiates outbound HTTP on behalf of a user or job as in scope until the vendor advisory narrows it.

• Attacker supplies or influences a target URL or host that MLflow will fetch.
• MLflow’s server-side client performs the request from a privileged network position.
• Internal or metadata responses may be reflected via status and body fields.

Am I affected? How to find it in your systems

MLflow is commonly deployed as a tracking server, model registry, or artifact service in research clusters, CI/CD for ML, Kubernetes namespaces, and cloud VMs used by data teams. Inventory every host and container that runs the MLflow server or related UI/API processes, including developer laptops that expose a local server and shared staging environments.

• Software inventory: package managers, container images, Helm charts, and orchestration manifests naming MLflow; configuration management and SBOM data for the same.
• Version and config check: compare installed MLflow versions and deployment mode (standalone server, behind reverse proxy, cloud-hosted) to the fixed and affected ranges in the vendor advisory—do not rely on guessed version lists.
• Exposure: map which instances are reachable from untrusted networks, corporate VPN only, or purely internal; note whether authentication and TLS terminate in front of MLflow.
• Telemetry: review reverse-proxy and application logs for unusual outbound request patterns originating from the MLflow process, spikes in requests toward link-local or metadata IP ranges, or anomalous API calls that embed full URLs. Absence of such logs does not prove safety if logging is incomplete.

Confirm detection signatures and indicators against the vendor advisory and your own baseline of legitimate artifact and registry traffic.

How to remediate

Patch first: apply the vendor-supplied update or mitigation package named in the official MLflow advisory for CVE-2026-64849, and verify the running binary or image digest afterward. Follow CISA’s direction to apply mitigations in accordance with vendor instructions and BOD 26-04 prioritization, including cloud-service guidance where MLflow is offered or hosted as a service. If no adequate mitigation exists, plan to discontinue use of the vulnerable product path until a fix is available.

• After patching, restart services cleanly and re-check version strings in health or admin endpoints you already trust.
• Harden outbound egress from MLflow hosts: default-deny egress, allow only required artifact stores, package indexes, and identity endpoints.
• Block or tightly control access to cloud metadata endpoints from application workloads (IMDSv2-style hop limits, network policies, or metadata proxies as appropriate to your cloud).
• Require strong authentication and least privilege on the MLflow API/UI; avoid exposing unauthenticated tracking servers.
• Segment MLOps workloads from high-value identity and production data planes.

If you can't patch immediately

Reduce risk with compensating controls until the vendor fix is deployed everywhere.

• Network segmentation and egress filtering so the MLflow process cannot reach internal admin interfaces or metadata services except through explicitly approved paths.
• Remove or restrict internet exposure; place the service behind VPN or zero-trust access with MFA.
• Virtual patching or WAF rules that block request patterns attempting to smuggle internal URLs, if your edge can inspect the relevant parameters—tune carefully to avoid breaking legitimate registry and artifact flows, and confirm rule guidance with the vendor when available.
• Disable or isolate any optional features that cause the server to fetch arbitrary remote resources, if your deployment allows and the advisory identifies them.
• Heighten monitoring: alert on MLflow-originated connections to link-local and metadata address ranges, and retain logs suitable for later forensics triage consistent with CISA expectations.

If your data may have been exposed

Actively exploited vulnerabilities can lead to environment compromise and data exposure even when ransomware use is not documented for a specific CVE. If MLflow could reach cloud metadata or internal services, treat possible credential and secret exposure as in scope: rotate cloud and service credentials that may have been readable from the host, review access logs for abuse, and follow your incident-response and CISA forensics triage practices. As a simple personal check, you can run a free exposure scan of your email against known breach datasets to see whether your address appears in publicly compiled breach records.