// threat brief

MLflow FileStore path traversal via trace ID: unauthenticated attackers can write trace files outside the intended folder

CVSS
8.2 HIGH
CISA KEV
Not listed
Weakness
CWE-22

PlainCVE Team · Published 2026-10-21 · AI-assisted · Press brief ↓

AI review 2026-10-21 (not human-reviewed)Command tests: none yetReproduced: not yetVerification record ↓

MLflow's FileStore backend lets unauthenticated attackers write trace files outside the intended folder via a crafted trace ID; no fix released yet.

Who is affectedMLflow servers on 3.17.1 or earlier that use the FileStore tracking backend. FileStore was the default before 3.7.0; from 3.7.0 on, only servers that explicitly choose FileStore are affected. No source says whether 3.17.2 is affected.
What happensWithin whatever the MLflow server process is allowed to write, an attacker can place MLflow trace files (trace_info.yaml, request metadata and tag files) containing attacker-controlled metadata outside the intended folder, and may cause a limited availability impact. The researcher says the demonstration does not show arbitrary file contents, code execution or data being read.
What to do nowThere is no fixed release yet. The researcher suggests restricting the trace-creation endpoint to trusted sources, or moving tracking to a SQL backend after checking compatibility. This advice does not come from MLflow.
Affected versions3.17.1 and earlier (the CVE record lists no lower bound; no source says whether 3.17.2 is affected)
Fixed versionsNone yet (no source reports a fixed version; fix PR #26842 is still labelled "proposed")
CVSS vector
Show full vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L
Timeline
  • First public 2026-10-17

Blue team playbook

Check, fix / mitigate, respond, harden. Matching the affected versions does not mean you were compromised, and a check that finds nothing does not prove you are safe; each item says what it can and cannot show. Tagged steps point to where the attack flow below can be stopped.

DETECTCheckAm I affected? Any signs of compromise?
  1. 01Check your MLflow version

    Run this inside the host, container or virtual environment (venv) that runs the MLflow server. 3.17.1 and earlier are listed as affected; no source covers 3.17.2, and our analysis is that it probably does not contain the fix.

    Read-only check
    pip show mlflow | grep -i '^version'
  2. 02Check whether the server uses FileStore

    PlainCVE suggestion: look at the MLflow server's startup arguments to see how the tracking backend (backend store) is configured. Before 3.7.0, no setting means FileStore; from 3.7.0 on, only an explicit FileStore choice is affected. Run on the server host.

    Read-only check
    ps -eo args | grep -i '[m]lflow server'
  3. 03Look for suspicious trace-creation requests

    PlainCVE suggestion: in the logs of the reverse proxy or web server in front of MLflow, look for POST /api/3.0/mlflow/traces requests from unexpected sources. The nginx log path below is an example; use your own log location.

    Read-only check
    grep -r "POST /api/3.0/mlflow/traces" /var/log/nginx/
  4. 04Look for trace files in the wrong place

    PlainCVE suggestion: on the MLflow server host or container, list every trace_info.yaml (skips /proc; searches all other locations including other mounts and container volumes, so it may be slow) and check for any outside your MLflow storage folder.

    Changes your environment
    find / -path /proc -prune -o -name trace_info.yaml -print 2>/dev/null
MITIGATEFix / mitigatePatch; block it if you cannot patch yet
  1. 01Restrict the trace-creation endpoint

    Researcher's suggestion: until a tested patch is deployed, restrict access to the trace-creation endpoint. This is not MLflow's advice.

  2. 02Move to a SQL tracking backend

    Researcher's suggestion: after checking compatibility, move trace tracking to a SQL backend. Since 3.7.0 the default is already SQLite. This is not MLflow's advice.

  3. 03Watch for an official fixed release

    The only fix so far is researcher-written PR #26842, not shown as merged or released. PlainCVE suggestion: upgrade once MLflow ships a release containing it, and check the release notes to confirm.

RESPONDRespondIf you find signs of compromise
  1. 01Preserve evidence, then remove unexpected files

    PlainCVE suggestion: if you find trace files outside the MLflow storage folder, back them up and record timestamps and the related requests before removing them, and check whether the extra files disrupted any service. The researcher says the demonstration does not show code execution or data being read, so the focus is the written files.

  2. 02Immediately close an exposed tracing endpoint

    PlainCVE suggestion: if logs show trace-creation requests from outside, first restrict endpoint access as the researcher suggests, then investigate.

HARDENHardenPrevent the next one
  1. 01Don't expose the MLflow tracking server without authentication

    PlainCVE suggestion: the researcher notes unauthenticated abuse depends on the endpoint having no authentication or access restrictions, so putting authentication or network limits in front should reduce exposure to unauthenticated abuse; this has not been tested.

  2. 02Run the server with least privilege

    PlainCVE suggestion: where files can be written is limited by the server process's permissions, so letting it write only to its own folder shrinks the impact.

Full remediation steps and notes
  1. There is no fixed release to upgrade to yet. Fix PR #26842 was written by the researcher (that page contains attack code, so this site does not link to it) and is labelled “proposed” in the CVE record; nothing shows it was merged or released. Our analysis: the 3.17.2 release notes don’t mention this fix and the PR’s release label moved from v3.17.2 to v3.17.3, so 3.17.2 probably does not contain it, but no source confirms this.
  2. Restrict access first. The researcher suggests restricting the trace-creation endpoint until a tested patch is deployed, or moving to a SQL backend after checking compatibility. Before switching backends, confirm your existing data and workflows will carry over. Neither suggestion comes from MLflow.
  3. Once a fix ships. PlainCVE suggestion: keep the access restrictions after upgrading, since an endpoint that accepts writes without login shouldn’t be exposed anyway.

Attack flow

Read left to right: this is the order the attack happens in. A blue shield means the step can be stopped; the earlier, the better. Click an icon for details.

Read top to bottom: this is the order the attack happens in. A blue shield means the step can be stopped; the earlier, the better. Tap an icon for details.

MLflow FileStore path traversal via trace ID: unauthenticated attackers can write trace files outside the intended folder: 1. Sends a trace-creation request to an MLflow server → 2. The server uses the FileStore tracking backend → 3. The trace ID is used to build a file path without checks → 4. Trace files are written outside the intended folderCVE-2026-53995 · MLflow FileStore path traversal via trace ID: unauthenticated attackerscan write trace files outside the intended folderAttackerYour systemSends a trace-creation request to an MLflow server — The CVE description says no login is needed. The researcher notes this depends on the tracing endpoint being exposed without authentication or access restrictions. 1Sends atrace-creationrequest to anMLflow serverThe server uses the FileStore tracking backend — FileStore was the default before 3.7.0; from 3.7.0 the default is SQLite, so only servers that explicitly choose FileStore are affected. 2The server usesthe FileStoretracking backendThe trace ID is used to build a file path without checks — If the client-supplied trace ID contains traversal sequences, the file path can escape the intended trace folder. 3The trace ID isused to build afile path withoutchecksTrace files are written outside the intended folder — trace_info.yaml, request metadata and tag files with attacker-controlled metadata get written; where they can land is limited by the server process's filesystem permissions, and the unexpected files and folders may cause a limited availability impact. 4Trace files arewritten outsidethe intended folderAttack pathCan be stopped herePlainCVE · plaincve.date/en/vulns/cve-2026-53995-mlflow-trace-id-path-traversal · CC BY 4.0
MLflow FileStore path traversal via trace ID: unauthenticated attackers can write trace files outside the intended folder: 1. Sends a trace-creation request to an MLflow server → 2. The server uses the FileStore tracking backend → 3. The trace ID is used to build a file path without checks → 4. Trace files are written outside the intended folderCVE-2026-53995 · MLflow FileStore pathtraversal via trace ID: unauthenticatedattackers can write trace files outsidethe intended folderSends a trace-creation request to an MLflow server — The CVE description says no login is needed. The researcher notes this depends on the tracing endpoint being exposed without authentication or access restrictions. 1AttackerSends a trace-creation requestto an MLflow serverThe server uses the FileStore tracking backend — FileStore was the default before 3.7.0; from 3.7.0 the default is SQLite, so only servers that explicitly choose FileStore are affected. 2Your systemThe server uses the FileStoretracking backendThe trace ID is used to build a file path without checks — If the client-supplied trace ID contains traversal sequences, the file path can escape the intended trace folder. 3Your systemThe trace ID is used to build afile path without checksTrace files are written outside the intended folder — trace_info.yaml, request metadata and tag files with attacker-controlled metadata get written; where they can land is limited by the server process's filesystem permissions, and the unexpected files and folders may cause a limited availability impact. 4Your systemTrace files are written outsidethe intended folderAttack pathCan be stopped herePlainCVE · CC BY 4.0plaincve.date/en/vulns/cve-2026-53995-mlflow-trace-id-path-traversal
Free to use in reporting and teaching under CC BY 4.0. Attribution is already on the image.
  1. Attacker

    Sends a trace-creation request to an MLflow server

    The CVE description says no login is needed. The researcher notes this depends on the tracing endpoint being exposed without authentication or access restrictions.

    Defense: Researcher's suggestion: until a tested patch is deployed, restrict the trace-creation endpoint to trusted sources.

  2. Your system

    The server uses the FileStore tracking backend

    FileStore was the default before 3.7.0; from 3.7.0 the default is SQLite, so only servers that explicitly choose FileStore are affected.

    Defense: Researcher's suggestion: move tracking to a SQL backend after checking compatibility.

  3. Your system

    The trace ID is used to build a file path without checks

    If the client-supplied trace ID contains traversal sequences, the file path can escape the intended trace folder.

    Defense: Proposed fix PR #26842 checks trace IDs so they cannot escape FileStore trace directories; it has not been shown to be merged or released.

  4. Your system

    Trace files are written outside the intended folder

    trace_info.yaml, request metadata and tag files with attacker-controlled metadata get written; where they can land is limited by the server process's filesystem permissions, and the unexpected files and folders may cause a limited availability impact.

    Defense: PlainCVE suggestion: run the MLflow server under a least-privilege account that can only write to its own storage folder.

Who is affected

ConditionAffected?
MLflow before 3.7.0 (within the ≤3.17.1 range), tracking backend left at defaultAffected (FileStore is the default)
MLflow 3.7.0 to 3.17.1 with FileStore explicitly selectedAffected
MLflow 3.7.0 to 3.17.1 using the default SQLite or another SQL backendThe CVE record says only explicit FileStore setups are affected
MLflow 3.17.2 (CHANGELOG says 2026-10-20; PyPI upload time is 2026-10-21 02:08 UTC)No source says; our analysis is that it is probably still unfixed
Fixed versionNone yet

The attacker also has to be able to reach the POST /api/3.0/mlflow/traces endpoint. The CVE description says no login is needed; the researcher adds that unauthenticated abuse depends on this tracing endpoint being exposed without authentication or access restrictions. When the flaw was introduced is unknown; the databases only list a placeholder lower bound of “0”.

How it works

MLflow is a platform for recording machine learning experiments and AI application runs. Each run record is called a trace and has a trace ID. With the FileStore backend, MLflow saves traces as files on the server, and the storage location is built from the trace ID.

The problem is that affected versions accept a trace ID from the client without making sure it has no traversal sequences such as “go up one folder”. As a result, MLflow writes trace_info.yaml, request metadata and tag files (containing attacker-controlled metadata) outside the intended trace folder. This kind of mistake is CWE-22 (path traversal).

Where the files can land is limited by the MLflow server process’s own filesystem permissions. The researcher says the demonstration does not show arbitrary file contents, code execution or data being read; the unexpected files and folders may cause a limited availability impact. The researcher’s proof of concept ran only in a local test setup and did not test a real deployment’s network exposure or authentication settings.

The flawed approach (conceptual illustration, not MLflow’s source code):

Show code example(python)
def trace_dir(base_dir, trace_id):
    # Pastes the client-supplied trace_id straight into the path
    return os.path.join(base_dir, trace_id)

The fixed approach (conceptual illustration):

Show code example(python)
def trace_dir(base_dir, trace_id):
    path = os.path.realpath(os.path.join(base_dir, trace_id))
    # The resulting path must stay inside the trace folder; otherwise reject
    if not path.startswith(os.path.realpath(base_dir) + os.sep):
        raise ValueError("invalid trace id")
    return path

The proposed PR #26842 aims to stop client-supplied trace IDs from escaping FileStore trace directories.

Timeline

DateEvent
2026-06-11CVE ID reserved
2026-10-13MLflow 3.17.1 released (last version listed as affected)
2026-10-17Public date given in the CVE record
2026-10-19CVE record published
2026-10-20MLflow 3.17.2 released per the CHANGELOG date (PyPI upload time is 2026-10-21 02:08 UTC; GitHub release shows 21 Oct); its release notes don’t mention this fix
2026-10-21As of this date, not in CISA KEV; NVD status is “Awaiting Analysis”

Further reading

  • Scores: The CNA (VulnCheck) gives both CVSS 3.1 8.2 (no confidentiality impact, high integrity impact, low availability impact) and CVSS 4.0 8.8 in the CVE record. NVD shows the CNA’s scores and has not done its own analysis yet (Awaiting Analysis). This page’s severity field uses the CNA’s CVSS 3.1 score of 8.2. The scores use different CVSS versions and do not conflict.
  • Exploitation: As of 2026-10-21 it is not in KEV; there is no evidence either way on exploitation in the wild or as a zero-day. CISA’s SSVC rating says a proof of concept exists and the flaw is automatable. EPSS is about 0.56% (45.6th percentile).
  • Credit: The CVE record credits Sai Teja Erukude; the researcher says disclosure was coordinated through VulnCheck, the CVE assigner. The researcher’s GitHub write-up includes proof-of-concept code (the page contains exploit material; we do not link it); where this page relies on its scope notes and workaround advice, we say so.
  • Vendor position: There is no MLflow security advisory or statement so far; GitHub Advisory Database entry GHSA-wqmh-qccw-pqwf has not been reviewed.
  • Related weakness type: CWE-22.

Verification Checked item by item against sources by AI under our review rules, all passed; not human-reviewed and not yet reproduced in our lab

AI review2026-10-21 · review rules

Verification records describe the environment and the result only, never reproduction steps or code that could attack other people’s systems. See our policy.

Sources

  1. CVE / NVD / OSVCVE-2026-53995 record (MLflow 3.17.1 and prior Path Traversal via Trace ID API) · CVE Program, 2026-10-19 · accessed 2026-10-21
  2. CVE / NVD / OSVNVD - CVE-2026-53995 (API) · NIST · accessed 2026-10-21
  3. AdvisoryMLflow Path Traversal via Trace ID API · VulnCheck · accessed 2026-10-21
  4. VendorMLflow CHANGELOG · MLflow (GitHub) · accessed 2026-10-21
  5. VendorMLflow releases · MLflow (GitHub) · accessed 2026-10-21
  6. OtherGitHub Advisory Database entry for CVE-2026-53995 (GHSA-wqmh-qccw-pqwf, unreviewed) · GitHub · accessed 2026-10-21
  7. OtherCVE-2026-53995: MLflow 3.17.1 and prior Path Traversal via Trace ID · HOL Guard · accessed 2026-10-21

Press brief

In one sentence

MLflow, a widely used open-source machine learning platform, has a path traversal flaw (CVE-2026-53995) in its FileStore tracking backend: an unauthenticated attacker can use a crafted trace ID to write trace files outside the intended folder if the tracing endpoint is reachable and, according to the researcher, exposed without authentication or access restrictions. Versions 3.17.1 and earlier are affected, and as of October 21, 2026 no source reports a fixed version; the only fix is a researcher-written pull request that, as of 2026-10-21, has not been shown to be merged or released. The researcher says the demonstration does not show code execution or data being read.

Key facts

Affected versions
MLflow 3.17.1 and earlier cveawg.mitre.org
CVSS 3.1 (CNA VulnCheck; the score used in this page's severity field)
8.2 cveawg.mitre.org
CVSS 4.0 (CNA VulnCheck)
8.8 cveawg.mitre.org
Fix availability
Not reported hol.org
Proposed fix
PR #26842 (written by the researcher; listed as "Proposed Pull Request" in the CVE record. That page contains attack code, so this site does not link to it) cveawg.mitre.org
CVE record published
2026-10-19 cveawg.mitre.org

Confirmed

  • In MLflow 3.17.1 and earlier, the FileStore tracking backend lets unauthenticated attackers write trace files outside the intended folder via a crafted trace ID (CVE record).
  • As of 2026-10-21 no source reports a fixed version, and the only fix, PR #26842, is labelled "proposed".
  • As of 2026-10-21 it is not in CISA's Known Exploited Vulnerabilities (KEV) catalog; CISA's SSVC rating says a proof of concept exists and it is automatable.

Unconfirmed / disputed

  • Whether MLflow 3.17.2 is affected: no source says; our analysis is that it probably does not contain the fix.
  • There is no evidence either way on exploitation in the wild or before a patch existed (zero-day).
  • When the flaw was introduced is unknown, and MLflow has published no security advisory or statement.

Quotable line

This flaw lets an attacker choose where trace files land and fill in some of their metadata, but the demonstration does not show arbitrary file contents; how much it matters depends on whether your server's door was left open.

Images

Download the share image (PNG) · Attack flow diagram (downloadable)

Please credit "PlainCVE" and link to this page. Full citation format is under "How to cite" below. Found a factual error? Report it.

How to cite this page

This article is CC BY 4.0. Please keep the attribution and link when republishing.

PlainCVE Team (2026). "MLflow FileStore path traversal via trace ID: unauthenticated attackers can write trace files outside the intended folder". PlainCVE. https://plaincve.date/en/vulns/cve-2026-53995-mlflow-trace-id-path-traversal (accessed YYYY-MM-DD)
BibTeX
@misc{cve202653995mlflowtraceidpathtraversal2026,
  title  = {MLflow FileStore path traversal via trace ID: unauthenticated attackers can write trace files outside the intended folder},
  author = {PlainCVE Team},
  year   = {2026},
  howpublished = {PlainCVE},
  url    = {https://plaincve.date/en/vulns/cve-2026-53995-mlflow-trace-id-path-traversal},
  note   = {Updated 2026-10-21}
}