MLflow CVE-2026-53995

Exploitation requires the MLflow tracking server to use the FileStore tracking backend AND be network-reachable on the POST /api/3.0/mlflow/traces endpoint. FileStore is the DEFAULT backend in MLflow versions before 3.7.0, so those deployments are exploitable without any special configuration; from 3.7.0 onward the default changed to a SQLite database, so later versions in the affected range (up to 3.17.1) are vulnerable ONLY when an operator has explicitly selected FileStore. No authentication is required (CVSS PR:N) and no user interaction is needed. The concrete limiting factors are: (1) the write occurs 'subject to the server process's filesystem permissions,' so impact scope is bounded by what the MLflow process user can write; (2) later-version deployments must have opted into FileStore; and (3) the server must be reachable from the attacker's network position.

Multiple signals converge on this being a genuine priority rather than a CVSS-inflated issue. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) describes a network-reachable, low-complexity, unauthenticated write with no user interaction, and the vendor-sourced base score is 8.8 with impact concentrated on integrity (VI:H) plus limited availability (VA:L) and no confidentiality impact (VC:N) - consistent with a write-only path traversal rather than data theft. Publicly available exploit code exists (GitHub PoC plus a VulnCheck advisory), which raises practical risk, but this is NOT the same as active exploitation: the input provides no CISA KEV listing and no EPSS score, so the real-world exploitation volume cannot be quantified from the data given. The absence of EPSS and SSVC decision data is a genuine gap - exploitation-probability and automatability cannot be asserted. The most important nuance is configuration-dependence: FileStore is the DEFAULT backend before MLflow 3.7.0 (vulnerable out of the box) but opt-in afterward (default moved to SQLite), so the true exposure of any given deployment depends on version and backend selection, not on the raw score alone. Net: treat exposed MLflow tracking servers on the FileStore backend as a high priority given the public PoC and unauthenticated network write; deployments on the later default (SQLite) are not affected unless FileStore was explicitly chosen.

An attacker who can reach an internet- or network-exposed MLflow tracking server sends a crafted request to the unauthenticated POST /api/3.0/mlflow/traces endpoint with a trace ID containing path traversal sequences (e.g. ../../). FileStore.start_trace() then writes trace_info.yaml, request_metadata, and tag files with attacker-controlled content to arbitrary locations outside the experiment trace directory, limited only by the server process's filesystem permissions, potentially overwriting configuration or other sensitive files. A public proof-of-concept exploit is available on GitHub, lowering the barrier to exploitation.