CVE-2026-53995: MLflow FileStore trace IDs allow path traversal and arbitrary file writes

FileStore.start_trace() builds a directory from the client-supplied trace ID without checking it. An ID with traversal sequences moves the target outside the experiment's trace folder. MLflow then writes trace_info.yaml, request metadata and tag files there, with attacker-chosen metadata, limited only by the server process's filesystem permissions.

No login is needed on a default MLflow server, since MLflow has no built-in authentication unless you enable it. The CVSS vector rates integrity as high and availability as low, with no confidentiality loss. An attacker can plant or overwrite YAML and metadata files in directories the server can write, which can corrupt other experiments or app data. The advisory does not claim code execution.

FileStore was the default backend before MLflow 3.7.0, so older installs are exposed without special setup. From 3.7.0 the default is a SQLite database, and only servers that choose FileStore are affected. Many teams run MLflow as a shared tracking server for agents and LLM apps, which makes the open endpoint reachable from other hosts on the network.

Affected: mlflow 3.17.1 and earlier, when the tracking backend is FileStore. That is the default before 3.7.0 and opt-in afterward. Check the version and the backend URI your server was started with:

pip show mlflow

A --backend-store-uri that is a plain path or a file: URI means FileStore. A sqlite: or other database URI means it is not in use.

Upgrade to MLflow 3.17.2.

pip install --upgrade "mlflow>=3.17.2"

The fix (pull request 26842) accepts only trace IDs that are safe directory names, checks that the resolved path stays inside the trace store, and guards metadata, tag and assessment paths against filesystem links. Invalid StartTraceV3 requests now return HTTP 400 with INVALID_PARAMETER_VALUE. The PR also notes the store directories must be writable only by trusted processes. The sources name no other workaround; moving to a database backend and keeping the server off untrusted networks lowers exposure.

Check the access log for POST /api/3.0/mlflow/traces requests whose body or trace ID contains .., slashes or encoded forms of them. On disk, look for trace_info.yaml files or tag and metadata files outside your experiment trace directories, and for files modified near those requests. After upgrading, such requests return a 400 error.

MLflow 3.17.1 and earlier contains a path traversal vulnerability in the FileStore tracking backend that allows unauthenticated attackers to control filesystem paths by submitting a crafted trace ID containing traversal sequences to the POST /api/3.0/mlflow/traces endpoint. Attackers can exploit FileStore.start_trace() to write trace_info.yaml, request_metadata, and tag files with attacker-controlled metadata outside the intended experiment trace directory, subject to the server process's filesystem permissions. FileStore is the default tracking backend before MLflow 3.7.0 and opt-in thereafter (the default changed to a SQLite database), so deployments in the earlier part of the affected range are vulnerable without special configuration while later ones are affected only when FileStore is explicitly selected.