CVE-2026-53995 in MLflow
Summary
by MITRE • 10/20/2026
MLflow 3.17.1 and earlier contains a path traversal vulnerability in the FileStore tracking backend that allows unauthenticated attackers to control filesystem paths by submitting a crafted trace ID containing traversal sequences to the POST /api/3.0/mlflow/traces endpoint. Attackers can exploit FileStore.start_trace() to write trace_info.yaml, request_metadata, and tag files with attacker-controlled metadata outside the intended experiment trace directory, subject to the server process's filesystem permissions. FileStore is the default tracking backend before MLflow 3.7.0 and opt-in thereafter (the default changed to a SQLite database), so deployments in the earlier part of the affected range are vulnerable without special configuration while later ones are affected only when FileStore is explicitly selected.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/20/2026
The vulnerability identified in MLflow versions prior to 3.17.1 represents a critical path traversal flaw within the FileStore tracking backend, specifically affecting the handling of trace identifiers during API interactions. This security issue arises from insufficient validation and sanitization of user-supplied input when processing requests directed at the POST /api/3.0/mlflow/traces endpoint. An unauthenticated attacker can exploit this weakness by submitting a crafted trace ID that includes directory traversal sequences, such as dot-dot-slash characters, to manipulate the underlying file system paths used for storing metadata files. This flaw allows the attacker to break out of the intended experiment trace directory and write arbitrary data into locations determined by their input rather than the application's default structure.
From a technical perspective, the vulnerability is rooted in how the FileStore.start_trace() method processes the provided identifier without adequately restricting path components. When an attacker supplies a maliciously constructed trace ID containing traversal sequences, the system fails to normalize or reject these inputs before using them as part of the file path for creating essential metadata files like trace_info.yaml, request_metadata, and tag files. Consequently, instead of placing these configuration artifacts within the secure, sandboxed directory associated with the specific experiment, the application writes them to arbitrary locations on the server's file system. The extent of this damage is directly constrained by the filesystem permissions granted to the MLflow server process, meaning that if the service runs with elevated privileges or broad write access, the impact can be severe.
The operational impact of this vulnerability extends beyond simple data corruption and includes potential remote code execution scenarios depending on the deployment context. By writing attacker-controlled metadata files outside the expected directory structure, an adversary may overwrite critical configuration files, inject malicious content into existing logs, or potentially achieve arbitrary file write capabilities that could lead to further exploitation vectors such as server-side request forgery or local privilege escalation if combined with other system weaknesses. This lack of input validation fundamentally undermines the integrity and isolation guarantees provided by the tracking backend, allowing an unauthenticated actor to disrupt service availability through resource exhaustion or data tampering across multiple experiments stored on the same file system.
In terms of industry standards classification, this vulnerability aligns closely with CWE-22: Improper Limitation of a Pathname to a Restricted Directory, as it involves accessing files outside the restricted directory intended by the application logic. Furthermore, from an offensive security perspective such as MITRE ATT&CK, this behavior is consistent with techniques involving file and directory manipulation for persistence or impact purposes, specifically falling under categories related to unauthorized access via path traversal which facilitates lateral movement within a compromised environment by manipulating local storage structures.
Mitigation strategies must prioritize immediate updates to MLflow version 3.17.1 or later where the input validation logic has been corrected to properly sanitize trace identifiers and prevent directory escape sequences from being processed as valid file paths. For deployments that cannot immediately upgrade, administrators should consider restricting network access to the tracking API endpoints by implementing strict authentication requirements before this vulnerability can be exploited remotely. Additionally, running the MLflow server with minimal filesystem permissions using principles of least privilege will significantly reduce the blast radius if an attacker manages to write files outside the intended directory structure. Organizations utilizing FileStore as their backend should also audit existing configurations and consider migrating to more secure backends like SQLite or database-backed solutions which do not rely on local file system path handling for core metadata storage, thereby eliminating this class of vulnerability entirely from the attack surface.