The Trace ID Is a Path: MLflow CVE-2026-53995 and the Fix That Is Still a Pull Request

2026-10-20 AI Vulnerabilities & CVEs by al-ice.ai Editorial

At 22:17:11Z on 19 October 2026, NVD published CVE-2026-53995, assigned by VulnCheck, rated 8.8 high on CVSS 4.0 with CWE-22, path traversal. MLflow 3.17.1 and earlier contains a traversal in the FileStore tracking backend: an unauthenticated attacker submits a crafted trace ID containing traversal sequences to POST /api/3.0/mlflow/traces, and FileStore.start_trace() writes trace_info.yaml, request-metadata and tag files — carrying attacker-controlled metadata — outside the intended experiment trace directory, anywhere the server process can write. Credit goes to researcher Sai Teja Erukude. MLflow (28,452 stars, Apache-2.0) is the experiment-tracking layer of a large fraction of the industry’s model pipelines, which is what elevates a file-write primitive into platform news: the thing being written is the integrity record of your training runs.

The affected population splits on a default change most operators never noticed. FileStore was the default tracking backend before MLflow 3.7.0; afterwards the default became a SQLite database, with FileStore opt-in. Deployments across the earlier part of the affected range are therefore vulnerable without any special configuration, while later ones are exposed only where FileStore was explicitly selected. If you upgraded MLflow across the 3.7.0 boundary years ago and never looked at the tracking URI again, this record is the reason to look now: the backend you stopped thinking about is the backend this CVE names.

The fix exists, and it is not merged

The remediation is mlflow/mlflow#26842, “Fix FileStore trace path traversal (CVE-2026-53995)” — and at time of writing its state is open, unmerged, against master. The proposal is well-shaped: trace IDs validated as safe directory names while preserving legitimate custom IDs containing dots, leading underscores and hyphens, spaces and Unicode; resolved-directory boundary checks before trace creation, lookup, search, updates and deletion; guards on metadata, tag and assessment paths against filesystem-link escapes; all deletion candidates validated before anything is deleted. Invalid requests get HTTP 400 with INVALID_PARAMETER_VALUE, and the validation is FileStore-specific so other backends keep their ID formats. The author reports 115 new regression tests passing on Windows.

Read the proposal’s own caveat, because it is doing honest work and it constrains your mitigation: “Containment uses the existing helper and retains its check/use race limitation; store directories must be writable only by trusted processes.” Even the planned fix keeps a time-of-check/time-of-use race and pushes residual safety onto directory permissions. Meanwhile the current release, v3.17.1 (13 October 2026), is the top of the affected range — there is no patched release to install, and the NVD references already include a public proof-of-concept repository under the reporter’s name, mirrored into exploit listings. This is the third time in a week we have written the sentence the fix is a pull request, not a release — see the BentoML batch and Xinference — and the window it opens is the same every time: disclosure with a public PoC on one side, and operators with nothing to upgrade to on the other.

What to do

There is no version to upgrade to, so the controls are architectural. Do not expose the tracking server to untrusted networks without authentication in front of it — this endpoint needs no credentials, and the request it accepts is a file write. Confirm which tracking backend each deployment actually uses: if it is FileStore on a version at or below 3.17.1, either migrate to the default SQLite-backed store or ensure the store directories are writable only by trusted processes, per the fix author’s own caveat. Audit existing trace directories for files outside their experiment paths — trace_info.yaml, metadata and tag files where no trace should have put them — because this primitive writes attacker-controlled metadata, the integrity question (which of my traces are real?) outlasts the availability one. Watch mlflow/mlflow#26842 and the release list past 3.17.1; when a fixed version lands, take it promptly rather than scheduling it, since the PoC is already public. Not in the CISA KEV catalogue (checked directly, 20 October 2026, 1,749 entries, zero hits); no exploitation reported.

Our verification was read-only. The CVE identifier, publication timestamp of 2026-10-19T22:17:11.013Z, the disclosure@vulncheck.com source identifier, the full description, the CWE-22 assignment and the CVSS 4.0 score were read first-hand from the NVD 2.0 API. The severity, affected range (≤ 3.17.1), researcher credit and advisory text were read directly from the VulnCheck advisory page. The fix proposal’s title, open state, base branch, full body — including the quoted check/use limitation — and every implementation detail above were read first-hand from the pull request via the GitHub API; the absence of a merged fix and the position of v3.17.1 (13 October 2026) as the newest release were measured directly, as was the repository metadata (28,452 stars, 6,482 forks, Apache-2.0). The public proof-of-concept repository is cited from the NVD reference list; exploit-listing mirrors were observed via search results only. KEV status was checked directly against the published catalogue. Brave Search was used for discovery only and returned the NVD-referenced PoC, CVE mirrors and exploit-listing entries, with no independent technical analysis of the record. We installed nothing, stood up no MLflow server, submitted no trace request, cloned no PoC repository and executed nothing; no third-party request was sent beyond reading the cited public records.

Sources: