---
id: "CVE-2026-118628"
kind: "vulnerability"
aliases: ["CVE-2026-118628"]
title: "MLflow: get-artifacts endpoint lets remote users read server-side data"
severity: "high"
cvss: 8.2
epss: null
exploited: false
status: "open"
category: "ai-tooling"
products: [{"name": "mlflow", "fixed": ["3.17.0"], "affected": "< 3.17.0", "ecosystem": "pypi"}]
ecosystems: []
tags: ["ai-tooling", "ml-platform", "mlflow", "python", "self-hosted", "ssrf", "unauthenticated"]
not_affected_if: ["auth-required", "managed-hosting", "not-network-reachable"]
published_at: "2026-11-04T00:17:24+00:00"
first_seen_at: "2026-11-04T00:46:16+00:00"
updated_at: "2026-11-04T00:48:49+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-118628", "first_seen_at": "2026-11-04T00:46:16+00:00"}, {"source": "analyst", "url": null, "first_seen_at": "2026-11-04T00:48:49+00:00"}]
---

# MLflow: get-artifacts endpoint lets remote users read server-side data

ZDI-26-844: MLflow's get-artifacts function does not validate a URI before accessing it, so a remote unauthenticated attacker can make the server connect to hosts of their choosing and disclose information in the server's context (CVSS 8.2). ZDI says it is fixed in MLflow 3.17.0. The upstream fix makes the tracking server refuse artifact locations on hosts other than its default artifact root or artifacts destination. No exploitation or public PoC found in the sources read.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- pypi:mlflow affected < 3.17.0 fixed 3.17.0

## How to check

- Run `pip show mlflow` or `mlflow --version` on every tracking server; versions below 3.17.0 lack the fix.
- Check whether the tracking server is reachable from the internet or untrusted networks; ZDI says no authentication is needed.
- Also check experiments' artifact_location and model version sources for hosts you do not recognize (ftp, sftp, hdfs, http/https and similar); the fix rejects those not matching the server's default artifact root.

## Fix

Upgrade MLflow to 3.17.0 or later (fix: mlflow PR #25891, GHSA-mr9f-g8qf-4w4j). If your artifact store is on a different host than --default-artifact-root / --artifacts-destination, set MLFLOW_ALLOWED_HOST_ADDRESSED_ARTIFACT_SCHEMES to the schemes you need after upgrading.

## Timeline

- 2026-11-04T00:46:16+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-118628
- 2026-11-04T00:48:49+00:00 analyst — ZDI-26-844 says fixed in 3.17.0 and links PR #25891 (GHSA-mr9f-g8qf-4w4j, SSRF via client-named artifact hosts). NVD page returned empty; GHSA page unreachable. Affected lower bound unknown; 3.17.0 only from ZDI. X not searched. Fix verified from ZDI/PR only.

## Documents

- [advisory] ZDI-26-844 MLflow get-artifacts SSRF https://www.zerodayinitiative.com/advisories/ZDI-26-844/
- [fix] mlflow PR 25891: refuse client-named artifact hosts (GHSA-mr9f-g8qf-4w4j) https://github.com/mlflow/mlflow/pull/25891

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_