- The NIST database lists CVE-2026-53995, a flaw in MLflow 3.17.1 and earlier that lets anyone without a login write files outside the intended folder.
- Exposure depends on the storage backend. Before version 3.7.0 the vulnerable one was the default, so teams may be exposed without ever choosing it.
- Inventory your MLflow servers, confirm each one's version and backend, check what the server account can write, and read the linked pull request and advisory.
Most security settings were chosen by someone. The one behind this MLflow flaw may not have been. It is a storage default, and your exposure may depend on when a team first installed the software.
What the record says
The NIST National Vulnerability Database published CVE-2026-53995 on October 19 and modified it on October 20. It covers MLflow 3.17.1 and earlier. The flaw is a path traversal in the FileStore tracking backend, the component that saves experiment records as files on disk.
The problem sits in the API route that accepts new traces, at POST /api/3.0/mlflow/traces. A person with no login can send a specially built trace ID that contains traversal sequences. According to the record, this gives that person control over where files land on the server.
How the attack works
Path traversal is an old and simple idea. A server builds a file location by joining a base folder with a name the client supplies. If the name contains sequences such as "../", the final path climbs out of the base folder.
Here, the NVD says the function FileStore.start_trace() builds paths from the trace ID in this way. The server then saves several files: trace_info.yaml, plus request metadata and tag files. Their contents are set by the attacker. They end up outside the experiment's intended trace directory.
The write is limited by the server process's filesystem permissions. The record does not say which files an attacker could reach. That depends on what the account running MLflow is allowed to change.
VulnCheck scored the flaw 8.2 under CVSS 3.1 and 8.8 under CVSS 4.0, both rated High. Both vectors show network access, low complexity, no privileges and no user interaction. Impact is high on integrity and low on availability. Confidentiality impact is none. In plain terms, the scoring treats this as tampering, not data theft.
The default is the real exposure question
The record describes a change of default in version 3.7.0. Before it, FileStore was what MLflow used unless told otherwise. From 3.7.0, a SQLite database became the default and FileStore turned into an opt-in choice.
The practical result, per the NVD, is a split. Servers running older versions in the affected range are open to the flaw with no special setup. Newer ones are affected only if someone deliberately picked FileStore.
This shows how risk can hide in a setting nobody reviewed. A team that set up tracking in the early days may never have decided to use FileStore. The software chose for them.
The record does not say what happens to an existing server's backend when it upgrades past 3.7.0. The safe inference is that exposure follows the backend in use. So confirm which backend a server runs after any upgrade, rather than assuming the newer default applies.
What is not yet known
The NVD record does not say the flaw is being exploited. It does not state a fixed version in its description. It lists a pull request in the MLflow repository (number 26842) and a VulnCheck advisory as references. Teams should read those directly before setting a remediation plan.
Questions to put to your team
Start with inventory. Ask who runs MLflow servers, including those set up by data or research groups outside central IT. Then ask four things about each one:
First, what version is it, and which tracking backend does it use? Second, can the tracking API be reached from outside a trusted network, and is anything requiring a login in front of it? Third, which account runs the server process, and what can that account write? Fourth, who owns the upgrade, and who confirms the backend setting afterward?
The lesson is simple. A patch tells you what changed in the software. Only an inventory tells you which defaults your own servers are still carrying.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: NIST NVD.
