Signal is active with 2 mentions in latest observed window
Recommended action window: Monitor and triage in normal cycle
NVD description
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.
Priority
LOW
Exploitation
NONE
PoC
NONE
Patch
NONE
Momentum
NONE
MLflow CVE-2026-118628: Unauth SSRF Alert Unauthenticated attackers can exploit get-artifacts in MLflow to trigger SSRF. Read ZeroPath's blog on this vuln and see our PoC and patch analysis. #AppSec #MLflow #InfoSec https://zeropath.com/blog/cve-2026-118628-mlflow-get-artifacts-ssrf
mlflow ships its tracking server without auth by default. CVE-2026-118628, CVSS 8.2, turns that into ssrf. create an experiment, set artifact_location to http://169.254.169.254/latest/meta-data/, then call get-artifacts. the server fetches whatever url the stored record names. no scheme check, no ip blocklist. the response comes back through get-artifacts, which means cloud credentials, internal services, port scans, all in the server's context. fixed in 3.17.0, PR #25891, which pins artifact hosts to the operator's default artifact root. the check to run this week: is your tracking server reachable, and is it still on a version before 3.17.0. auth alone is not the fix here, the fix is the host policy. and if you run the wsgi app directly instead of mlflow server, export the env var, or the registry check stays off. write-up: https://zeropath.com/blog/cve-2026-118628-mlflow-get-artifacts-ssrf