CVE-2026-118628: MLflow: unauthenticated SSRF in get-artifacts leaks data

AWAITING NVD

Published November 3, 2026

CISO Take

MLflow's get-artifacts function does not validate the URI it is given before fetching it, so an unauthenticated remote attacker can make the server issue requests on their behalf (SSRF, CWE-718 class) and read back the responses. MLflow is a core ML lifecycle platform with 695 downstream dependents, 95 other CVEs on record and an OpenSSF Scorecard of 5.4/10, so the exposure and supply-chain risk are both material. Severity and CVSS are not yet scored, there is no EPSS data, no public exploit, no Nuclei template and no KEV listing, so there is no sign of active exploitation today. The real danger is that an SSRF on a cloud-hosted tracking server can reach instance metadata endpoints and internal services and expose cloud credentials, which turns a bug that looks minor into a path to broader compromise. Check the ZDI advisory (ZDI-26-844) and the MLflow release notes for a fixed version, apply it as soon as it ships, and until then put the tracking server behind authentication and restrict its egress.

Sources:NVDZDIATLASOpenSSF

What is the risk?

Provisional risk is HIGH, because the flaw is unauthenticated, remotely reachable and needs no user interaction, and no CVSS score has been published yet. Exploitation likelihood is currently unknown: EPSS is unavailable, no public exploit or scanner template exists, and the CVE is not in CISA KEV. The impact is information disclosure in the context of the server, and it could escalate if the host can reach cloud metadata services or internal APIs. Exposure is highest for MLflow tracking servers that are internet-facing or run without an authentication proxy, which is a common default in internal ML platforms. Confidence: MEDIUM, since the only source is a ZDI advisory and no patched version range has been published.

How does the attack unfold?

Reconnaissance

The attacker finds an internet-reachable MLflow server that exposes the get-artifacts function.

AML.T0006

Initial Access

The attacker sends an unauthenticated request with a crafted URI to the get-artifacts function.

AML.T0049

Exploitation

The server fetches the attacker-chosen internal or metadata resource because the URI is not validated.

AML.T0035

Impact

Sensitive internal data or cloud credentials are returned to the attacker, enabling further access to ML assets.

AML.T0025

Reconnaissance

The attacker finds an internet-reachable MLflow server that exposes the get-artifacts function.

AML.T0006

Initial Access

The attacker sends an unauthenticated request with a crafted URI to the get-artifacts function.

AML.T0049

Exploitation

The server fetches the attacker-chosen internal or metadata resource because the URI is not validated.

AML.T0035

Impact

Sensitive internal data or cloud credentials are returned to the attacker, enabling further access to ML assets.

AML.T0025

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
MLflow	pip	—	No patch
28.6KOpenSSF 5.4695 dependentsPushed 2d ago36% patched~68d to patchFull package profile →

Do you use MLflow? You're affected.

How severe is it?

CVSS 3.1

N/A

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Trivial

What should I do?

1 step

1) Identify all MLflow servers (pip 'mlflow') and confirm which are network-reachable, and monitor the vendor release notes and ZDI-26-844 for the fixed version, then upgrade promptly. 2) Until patched, do not expose the tracking server directly to the internet. Put it behind an authenticating reverse proxy or VPN and limit access to known clients. 3) Restrict outbound traffic from the MLflow host with egress filtering, and block access to link-local metadata addresses (169.254.169.254). Enforce IMDSv2 with hop limit 1 on AWS, or the equivalent on other clouds. 4) Give the MLflow service identity least-privilege cloud roles so stolen credentials have limited value. 5) Detection: alert on requests to get-artifacts containing unusual URI schemes, internal IP ranges, localhost or metadata hostnames, and on unexpected outbound connections from the MLflow host to internal networks.

How is it classified?

Data LeakageData ExtractionFrameworkAPIAML.T0025- Exfiltration via Cyber Means AML.T0035- AI Artifact Collection AML.T0049- Exploit Public-Facing Application

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art. 15-Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.6-AI system operation and monitoring

NIST AI RMF

MANAGE 2.3-Responses to previously unknown risks and mechanisms to supersede deployed systems

OWASP LLM Top 10

LLM03-Supply Chain

Frequently Asked Questions

What is CVE-2026-118628?

Is CVE-2026-118628 actively exploited?

No confirmed active exploitation of CVE-2026-118628 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-118628?

1) Identify all MLflow servers (pip 'mlflow') and confirm which are network-reachable, and monitor the vendor release notes and ZDI-26-844 for the fixed version, then upgrade promptly. 2) Until patched, do not expose the tracking server directly to the internet. Put it behind an authenticating reverse proxy or VPN and limit access to known clients. 3) Restrict outbound traffic from the MLflow host with egress filtering, and block access to link-local metadata addresses (169.254.169.254). Enforce IMDSv2 with hop limit 1 on AWS, or the equivalent on other clouds. 4) Give the MLflow service identity least-privilege cloud roles so stolen credentials have limited value. 5) Detection: alert on requests to get-artifacts containing unusual URI schemes, internal IP ranges, localhost or metadata hostnames, and on unexpected outbound connections from the MLflow host to internal networks.

What systems are affected by CVE-2026-118628?

This vulnerability affects the following AI/ML architecture patterns: Training pipelines, Experiment tracking servers, Model registries, MLOps platforms, Model serving.

What is the CVSS score for CVE-2026-118628?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

Training pipelinesExperiment tracking serversModel registriesMLOps platformsModel serving

MITRE ATLAS Techniques

AML.T0025Exfiltration via Cyber Means

AML.T0035AI Artifact Collection

AML.T0049Exploit Public-Facing Application

Compliance Controls Affected

EU AI Act: Art. 15

ISO 42001: A.6.2.6

NIST AI RMF: MANAGE 2.3

OWASP LLM Top 10: LLM03

What are the technical details?

Original Advisory

MLflow get-artifacts Server-Side Request Forgery Information Disclosure Vulnerability. This vulnerability allows remote attackers to disclose sensitive information on affected installations of MLflow. Authentication is not required to exploit this vulnerability. The specific flaw exists within the get-artifacts function. The issue results from the lack of proper validation of a URI prior to accessing resources. An attacker can leverage this vulnerability to disclose information in the context of the server. Was ZDI-CAN-28192.

Exploitation Scenario

An attacker finds an internet-exposed MLflow tracking server through a scan. Without any credentials, they call the get-artifacts endpoint with a crafted URI that points to the cloud metadata service or an internal admin interface. The server fetches the resource and returns its contents, giving the attacker temporary cloud credentials or internal configuration data. With those credentials they enumerate and download model artifacts, datasets and secrets from the associated storage buckets, and may pivot further into the ML platform.

Weaknesses (CWE)

CWE-918Server-Side Request ForgeryPrimary CWE-918Server-Side Request Forgery

CWE-918 — Server-Side Request Forgery: The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.

[Implementation, Operation] If there is a known list of applications, IP, hostname, and/or domains to which the product is allowed to communicate, then use allowlists to ensure that outgoing requests are restricted to these known entities. The allowlists could be in the application code or possibly enforced by firewalls or network segmentation [REF-1511].
[Implementation, Operation] If the product is expected to be able to connect to arbitrary IP addresses or domains, consider using a denylist that includes private network addresses, internal domain names, etc. The denylist could be in the application code or possibly enforced by firewalls or network segmentation [REF-1511].

Source: MITRE CWE corpus.