MLflow 3.18.0 fixes a flaw that let anyone write files on servers using the FileStore backend — update now

Update, November 5, 2026: A fix has shipped. The MLflow changelog for version 3.18.0 (dated November 2, 2026; on PyPI since November 3) lists "Fix FileStore trace path traversal (CVE-2026-53995) (#26842)", together with related hardening that validates trace, assessment and model IDs as single path components. The 3.17.2 patch release of October 20 does not include the fix, so treat every version below 3.18.0 as vulnerable. This article was first drafted on October 21, when no fixed version existed; the text below has been updated accordingly.

A path traversal flaw in MLflow, tracked as CVE-2026-53995 and published on October 19, 2026, lets an unauthenticated attacker write files outside their intended folder on MLflow tracking servers that use the file-based "FileStore" backend. The public advisories list versions up to and including 3.17.1 as affected; the fix first appears in MLflow 3.18.0. If you run MLflow with FileStore, update to 3.18.0, restrict who can reach the server, and plan a move to a database backend.

What happened, in plain English

MLflow is open-source software that data science and machine-learning (ML) teams use to record their experiments and store trained models. Many organisations run a shared MLflow "tracking server" on their internal network, and newer versions also record traces — logs of what an AI application or agent did step by step.

When a client sends a new trace to the server, it includes a trace ID, a name for that trace. On servers that store data as ordinary files and folders (the FileStore backend), MLflow uses that ID to build the folder name where the trace's files are saved. The problem: the server did not check the ID properly. An ID containing "go up one folder" sequences — this is what path traversal means — makes the server write its files somewhere else entirely.

An analogy: a filing clerk who puts each new folder wherever the label on it says, without noticing that one label reads "not in the archive, put this in the manager's office".

Three things make this worth attention. The attacker does not need to log in. The trace endpoint is part of MLflow's normal API, so anyone who can reach the server can call it. And the person who reported it has published a proof-of-concept.

The limits matter too. The files written are MLflow's own trace files (trace_info.yaml, request metadata and tag files), with content the attacker partly controls, and the attacker can only write where the MLflow server process itself has permission to write. Servers using a database backend (SQLite, PostgreSQL, MySQL and others) are not affected.

Are you affected? What to do now

You are potentially affected only if all of these are true: you run an MLflow tracking server yourself (self-hosted), it is older than version 3.18.0, and it uses the FileStore backend. FileStore was the default before MLflow 3.7.0; from 3.7.0 the default is SQLite and FileStore must be chosen explicitly. Managed MLflow services run by cloud vendors are not covered by the public advisory — check with your provider. If your team does not run MLflow, there is nothing to do.

Check

• Version: on the server, run pip show mlflow or mlflow --version. Anything below 3.18.0 is in scope — including 3.17.2, which does not contain the fix.
• Backend: look at how the server is started. A --backend-store-uri that is a local path (for example ./mlruns or file:/...) means FileStore. A database URI (sqlite:///..., postgresql://..., mysql+...://...) means you are not affected by this flaw. On versions before 3.7.0, no --backend-store-uri at all also means FileStore.
• Exposure: check what address the server listens on (--host). 127.0.0.1 means local only; 0.0.0.0 means every network interface. Check whether anything outside your team — or the internet — can reach the port.

Do, in this order

• Update to MLflow 3.18.0. It is a feature release, and its changelog lists breaking changes, so test it on a copy of your server first if you can. If you cannot update straight away, apply the steps below in the meantime.
• Restrict access now. Block the MLflow port at the firewall or security group for everyone who does not need it. Never expose an unauthenticated tracking server to the internet.
• Add authentication. Put the server behind a reverse proxy with login, or enable MLflow's built-in basic authentication (mlflow server --app-name basic-auth). This turns an unauthenticated attack into one that needs valid credentials.
• Run with least privilege. Make sure the MLflow process runs as a dedicated user that can write only to its own data directory — that caps what a traversal write can reach.
• Plan the move off FileStore. MLflow's documentation marks the file backend as "in maintenance mode" and soon to be deprecated, and recommends a database backend; follow MLflow's migration guide after testing compatibility.
• Look for traces of misuse. No official indicators of compromise have been published. A reasonable check is your reverse-proxy or server logs for unusual POST requests to /api/3.0/mlflow/traces from unexpected sources, and for trace files appearing outside the normal experiment directories. Updating does not remove files that were already written.

As of November 5, 2026, there are no public reports of this flaw being exploited, and it is not in the U.S. Cybersecurity and Infrastructure Security Agency's (CISA) Known Exploited Vulnerabilities catalog.

The expert view

Root cause. This is CWE-22, improper limitation of a pathname to a restricted directory. A client-supplied identifier flowed into filesystem path construction in FileStore.start_trace() without being validated as a safe single path segment. It is a textbook bug in a new code path: tracing arrived with MLflow's push into generative-AI and agent observability, while FileStore is a legacy backend the project has already put into maintenance mode. New features bolted onto old storage layers are a recurring source of this class of flaw.

Attack chain, conceptually. Reach the tracking API, create a trace whose ID escapes the trace directory, and the server writes its metadata files to an attacker-chosen location within the process's write permissions. No credentials, no user interaction. The fix in 3.18.0 rejects IDs that are not a single path component (absolute paths, separators, "." or "..", and names Windows would normalise into them), and additionally rejects new trace IDs containing %, ?, # or control characters. The 3.18.0 changelog also lists related changes that apply the same check to trace deletion, assessment IDs and model IDs. The reporter noted that lookup and deletion concerns came from source review, not the published proof-of-concept, which only covers trace creation.

Why defenses failed. MLflow's tracking server has historically been designed as a trusted-network tool: authentication is optional and off unless configured. MLflow 3.x added host-header validation and CORS defaults, which help against browser-based attacks, but they are not access control — a client on an allowed network can still call the API directly.

Severity in context. VulnCheck, the CVE Numbering Authority for this record, scores it CVSS 4.0 8.8 and CVSS 3.1 8.2 (High), with high integrity impact and low availability impact and no confidentiality impact. That is a fair ceiling, but for most environments it is somewhat overrated in practice: the written files have a fixed name and structure, the reporter explicitly says the demonstrated writes do not establish arbitrary file contents or code execution, and recent MLflow versions only use FileStore by explicit choice. Where it can bite: older pre-3.7 deployments that never changed defaults, servers run as root or in containers with broad write access, and shared servers where one tenant can tamper with another's experiment data — an integrity problem in a system whose whole purpose is to be the record of how models were built. Treat speculation about remote code execution with caution until someone demonstrates it.

The broader trend. MLflow has been a steady target in 2026. CISA added an earlier MLflow flaw, CVE-2026-64849, to its exploited-vulnerabilities catalog on August 19, and other recent advisories covered unsafe model loading. MLOps platforms sit next to training data, model artifacts and cloud credentials, and attackers have noticed. The lesson is the same each time: these servers need the same network isolation and authentication as any other production system.

Still unknown. The GitHub advisory and the CVE record have not yet been updated to name a patched version, and the MLflow maintainers have not published a separate advisory of their own.

Official sources

• VulnCheck advisory — CVE-2026-53995: MLflow Path Traversal via Trace ID API (October 19, 2026)
• CVE-2026-53995 — CVE record (CNA: VulnCheck)
• NVD — CVE-2026-53995
• GitHub advisory GHSA-wqmh-qccw-pqwf
• MLflow changelog — 3.18.0 (November 2, 2026)
• MLflow fix commit — "Fix FileStore trace path traversal (CVE-2026-53995) (#26842)"
• MLflow pull request #26842
• Researcher disclosure — Sai Teja Erukude
• MLflow documentation — Backend stores (FileStore in maintenance mode)
• MLflow documentation — Tracking server security
• MLflow release history on PyPI
• Coverage: VulDB — CVE-2026-53995