Summary
MLflow's FileStore tracking backend contains a path traversal vulnerability that allows unauthenticated attackers to influence filesystem paths through a crafted trace ID submitted to the trace API.
If the server uses FileStore and the process has write access to affected locations, an attacker may write trace-related files outside the intended experiment directory.
MLflow's FileStore tracking backend contains a path traversal vulnerability that allows unauthenticated attackers to influence filesystem paths through a crafted trace ID submitted to the trace API.
If the server uses FileStore and the process has write access to affected locations, an attacker may write trace-related files outside the intended experiment directory.
Affected context
The vulnerability occurs in MLflow deployments using the FileStore tracking backend when trace IDs are incorporated into filesystem paths without adequately restricting traversal sequences. FileStore was the default tracking backend in earlier affected releases and may still be selected explicitly in later deployments. Exploitation is limited by the filesystem permissions of the MLflow server process.
The vulnerability occurs in MLflow deployments using the FileStore tracking backend when trace IDs are incorporated into filesystem paths without adequately restricting traversal sequences. FileStore was the default tracking backend in earlier affected releases and may still be selected explicitly in later deployments. Exploitation is limited by the filesystem permissions of the MLflow server process.
Exploit preconditions
- Attack surface: The MLflow trace API, specifically the
POST /api/3.0/mlflow/tracesendpoint - Required access: Network access to the endpoint; authentication is not required according to the vulnerability description
- Trigger point: Processing a crafted trace ID by
FileStore.start_trace() - Why exploitation is possible: Traversal sequences in the trace ID can influence paths used for writing trace metadata and tag files
- Environmental limitation: The server process must have write permission to the targeted filesystem locations
- Attack surface: The MLflow trace API, specifically the
POST /api/3.0/mlflow/tracesendpoint - Required access: Network access to the endpoint; authentication is not required according to the vulnerability description
- Trigger point: Processing a crafted trace ID by
FileStore.start_trace() - Why exploitation is possible: Traversal sequences in the trace ID can influence paths used for writing trace metadata and tag files
- Environmental limitation: The server process must have write permission to the targeted filesystem locations
Why this happens
The underlying issue is insufficient canonicalization and boundary enforcement when attacker-influenced trace identifiers are converted into filesystem paths.
When path components derived from external input are joined with a trusted storage directory without rejecting traversal sequences or verifying the resulting canonical path, the input can escape the intended directory. This behavior maps to CWE-22: Improper Limitation of a Pathname to a Restricted Directory.
The underlying issue is insufficient canonicalization and boundary enforcement when attacker-influenced trace identifiers are converted into filesystem paths.
When path components derived from external input are joined with a trusted storage directory without rejecting traversal sequences or verifying the resulting canonical path, the input can escape the intended directory. This behavior maps to CWE-22: Improper Limitation of a Pathname to a Restricted Directory.
Potential impact
- An attacker may write
trace_info.yaml, request metadata, or tag files outside the intended trace directory. - Malicious files may overwrite or interfere with data if the process has suitable permissions.
- Application behavior or tracking data could be altered.
- The vulnerability could support further compromise if writable locations influence executable, configuration, or operational files.
- An attacker may write
trace_info.yaml, request metadata, or tag files outside the intended trace directory. - Malicious files may overwrite or interfere with data if the process has suitable permissions.
- Application behavior or tracking data could be altered.
- The vulnerability could support further compromise if writable locations influence executable, configuration, or operational files.
General mitigation guidance
Mitigation generally focuses on eliminating attacker control over filesystem paths and enforcing storage boundaries.
Common defensive patterns include:
- Treating trace IDs and related identifiers as opaque values rather than path components.
- Rejecting traversal syntax and path separators before path construction.
- Canonicalizing candidate paths and verifying that they remain beneath an intended storage root.
- Using generated, constrained identifiers for filesystem names and storing untrusted values as file content or database fields.
- Applying least-privilege filesystem permissions and isolating tracking data from sensitive application directories.
- Prefering storage backends that do not derive filesystem paths directly from request-controlled identifiers where appropriate.
Mitigation generally focuses on eliminating attacker control over filesystem paths and enforcing storage boundaries.
Common defensive patterns include:
- Treating trace IDs and related identifiers as opaque values rather than path components.
- Rejecting traversal syntax and path separators before path construction.
- Canonicalizing candidate paths and verifying that they remain beneath an intended storage root.
- Using generated, constrained identifiers for filesystem names and storing untrusted values as file content or database fields.
- Applying least-privilege filesystem permissions and isolating tracking data from sensitive application directories.
- Prefering storage backends that do not derive filesystem paths directly from request-controlled identifiers where appropriate.
How teams detect issues like this
Organizations can look for:
- Static analysis findings involving direct concatenation or joining of request data with filesystem paths.
- Code review signals such as trace IDs, run IDs, or user-controlled names being used as directory or filename components.
- Tests that exercise canonical-path validation and attempts to escape configured storage roots.
- Runtime monitoring for unexpected writes outside the configured MLflow artifact or trace directory.
- Policy checks requiring path-boundary validation and least-privilege service accounts for tracking servers.
Automated security review tools can help identify path construction APIs that receive unsanitized request data.
Organizations can look for:
- Static analysis findings involving direct concatenation or joining of request data with filesystem paths.
- Code review signals such as trace IDs, run IDs, or user-controlled names being used as directory or filename components.
- Tests that exercise canonical-path validation and attempts to escape configured storage roots.
- Runtime monitoring for unexpected writes outside the configured MLflow artifact or trace directory.
- Policy checks requiring path-boundary validation and least-privilege service accounts for tracking servers.
Automated security review tools can help identify path construction APIs that receive unsanitized request data.
