MLflow: path traversal in FileStore trace IDs lets unauthenticated writes outside the tracking directory

CVSS 8.8CVE-2026-53995AI/ML frameworks & servingcurated

Impact

An unauthenticated caller who can reach the MLflow tracking server submits a trace ID containing traversal sequences and makes FileStore.start_trace() write trace_info.yaml, request_metadata and tag files, with attacker-controlled contents, anywhere the server process can write. On a GPU fleet the tracking server usually runs with broad access to the shared experiment store and often to the artifact root, so this is a write primitive into paths other tenants and jobs read back - config, scripts picked up by training entrypoints, or files on a shared parallel filesystem. MLflow endpoints are commonly left unauthenticated behind a cluster-internal URL, so in practice anyone with pod network reach is enough. FileStore is the default backend before MLflow 3.7.0 and opt-in after, so older deployments are exposed with no special configuration.

Who can reach it

Anyone who can reach the MLflow tracking server's HTTP port. No authentication required. Deployments before 3.7.0 are affected by default; 3.7.0 and later only when FileStore is explicitly selected instead of the SQLite/SQL backend.

What to do

Upgrade MLflow past 3.17.1 (fix in PR 26842) and restart the tracking server - a service restart, no node drain. If an upgrade is not immediate, switch the tracking backend off FileStore to a SQL store and keep the tracking endpoint off tenant-reachable networks behind authentication.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-53995 https://www.vulncheck.com/advisories/mlflow-path-traversal-via-trace-id-api https://github.com/mlflow/mlflow/pull/26842

Related entries

All AI/ML frameworks & serving entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.