CVE-2025-11201

What it actually does

CVE-2025-11201 is an unauthenticated path traversal vulnerability in MLflow Tracking Server model creation/file-path handling. The server fails to properly canonicalize and constrain user-supplied model paths before performing file operations, allowing a remote attacker to escape the intended model/artifact directory. If the attacker can place or overwrite files in locations that are later executed, imported, loaded, or interpreted by the service or operating system, the issue can become remote code execution in the context of the MLflow service account. The practical impact is arbitrary file write or overwrite leading to code execution, persistence, credential access, or service compromise depending on filesystem permissions.

Why it matters to the business

A vulnerable MLflow Tracking Server can be compromised remotely without authentication, which is especially serious for organizations using MLflow to manage machine-learning experiments, models, artifacts, credentials, or deployment workflows. Successful exploitation could let an attacker tamper with models, steal experiment data or tokens, disrupt model operations, pivot into adjacent infrastructure, or implant code that runs under the service account. Although this CVE is not currently listed in CISA KEV and the provided exploit maturity is none, the EPSS score is elevated and the issue has been public for 285 days, so internet-exposed or broadly reachable MLflow services should be treated as high priority.

How an attack unfolds

An attacker first identifies a reachable MLflow Tracking Server. Because authentication is not required for the vulnerable operation, the attacker sends a crafted model creation or model file operation request containing path traversal sequences such as ../ or encoded equivalents. The server trusts the supplied path and performs filesystem operations outside the intended MLflow model or artifact directory. The attacker then uses this write capability to place or overwrite a file that will be executed, imported, interpreted, or loaded by MLflow, Python, a startup mechanism, or a related service. Once execution is triggered, the payload runs with the privileges of the MLflow service account, allowing the attacker to run commands, establish persistence, access MLflow-managed data and credentials, and move laterally if the host has access to other systems.

How to fix it

Upgrade affected software to a fixed version and remove direct unauthenticated exposure. For the listed Git-based MLflow package, update to commit 2e02bc7bb70df243e6eb792689d9b8eba0013161 or a later trusted release containing that fix. For listed Red Hat packages, update qemu-img-rhev, qemu-kvm-common-rhev, qemu-kvm-rhev, qemu-kvm-rhev-debuginfo, and qemu-kvm-tools-rhev to 10:2.12.0-33.el7 or later where applicable in the deployed product set. Because the affected-products list contains both MLflow and Red Hat virtualization package entries, validate applicability against actual installed components rather than relying on name matching alone. As compensating controls, require authentication in front of MLflow, restrict network access to trusted users and services, block internet exposure, run MLflow under a dedicated low-privilege account, prevent the service account from writing to executable paths, mount artifact/model storage with restrictive permissions where possible, and monitor or deny path traversal patterns at the reverse proxy or WAF layer. Application-level fixes should canonicalize paths, reject absolute paths and traversal components, and enforce that resolved paths remain under the intended base directory before any file operation.

How to confirm the fix worked

Confirm deployed versions after patching. For Git-based MLflow deployments, verify that the running code includes commit 2e02bc7bb70df243e6eb792689d9b8eba0013161 or a later fixed commit. For Red Hat package deployments where applicable, verify installed RPM versions with package inventory tooling and confirm the listed packages are at 10:2.12.0-33.el7 or later. Validate configuration by confirming the MLflow Tracking Server is not publicly reachable and requires authentication or is only reachable through trusted network controls. Perform a non-destructive test in a staging environment by submitting model/file-path values containing ../, ..\\, and URL-encoded traversal sequences and confirm the server rejects the request or normalizes it safely without creating or modifying files outside the intended artifact/model directory. Review filesystem permissions to ensure the MLflow service account cannot write to startup directories, Python package directories, shell profiles, SSH authorized keys, cron directories, systemd unit paths, or other executable locations.

Typical attack path

1. Discover an exposed or reachable MLflow Tracking Server.
2. Confirm that unauthenticated MLflow API requests are accepted.
3. Send a crafted model creation or file-path request containing traversal sequences such as ../, ..\\, or URL-encoded variants.
4. Use the traversal to write or overwrite files outside the intended model/artifact directory.
5. Place a payload in a location that is later executed, imported, loaded, or invoked by the service or operating system.
6. Trigger execution through service behavior, restart behavior, model loading, Python import behavior, or another execution path available on the host.
7. Run commands as the MLflow service account, collect data, modify models, add persistence, or pivot to adjacent infrastructure.

How to detect it

Review reverse-proxy, load balancer, web server, and MLflow application logs for unauthenticated requests to MLflow model or artifact APIs containing directory traversal sequences, including URL-encoded variants. Correlate suspicious requests with filesystem events showing the MLflow service account writing outside expected tracking, model, or artifact directories. Use endpoint detection, auditd, Sysmon for Linux, eBPF telemetry, or EDR to identify child processes spawned by the MLflow service, especially shells, interpreters, download tools, or networking utilities. Examine recent file creations and modifications in persistence-sensitive locations such as cron directories, systemd unit directories, shell profile files, Python site-packages, MLflow working directories, temporary directories, and SSH authorized_keys files. Review MLflow metadata and model registry activity for unusual model names, artifact paths, source paths, or creation events containing traversal strings, absolute paths, hidden directories, or encoded path separators. If suspicious activity is found, preserve logs and disk artifacts, isolate the host, compare model/artifact directories against known-good backups, and rotate credentials accessible to the MLflow service account.

• ../
• ..\\
• %2e%2e%2f
• %2e%2e%5c
• ..%2f
• ..%5c
• %252e%252e%252f
• %252e%252e%255c
• /api/2.0/mlflow/registered-models/create
• /api/2.0/mlflow/model-versions/create
• /api/2.0/mlflow/artifacts
• /ajax-api/2.0/mlflow/registered-models/create
• /ajax-api/2.0/mlflow/model-versions/create
• /etc/passwd
• /etc/shadow
• /etc/cron.d/
• /etc/systemd/system/
• /root/.ssh/authorized_keys
• /.ssh/authorized_keys
• site-packages
• bash -c
• sh -c
• python -c
• curl
• wget
• nc -e
• ncat -e
• /bin/bash
• /bin/sh
• mlflow

What your security team should do

• Inventory all MLflow Tracking Server instances and determine whether any are internet-facing or reachable by untrusted users.
• Patch or upgrade Git-based MLflow deployments to commit 2e02bc7bb70df243e6eb792689d9b8eba0013161 or later; apply the listed Red Hat fixed package versions where those packages are actually present and applicable.
• Immediately place MLflow behind authentication and network access controls if it is currently unauthenticated or broadly reachable.
• Hunt for prior exploitation using web access logs, MLflow application logs, filesystem telemetry, endpoint telemetry, and process execution logs.
• Search for traversal strings and suspicious model creation activity in historical logs, including encoded traversal variants.
• Review files modified by the MLflow service account outside expected MLflow tracking, model, and artifact directories.
• Investigate any shell, Python, curl, wget, nc, bash, sh, or reverse-shell process spawned by the MLflow service process.
• Rotate secrets accessible to the MLflow service if suspicious activity is found, including repository credentials, cloud credentials, API tokens, and database credentials.
• Apply least-privilege filesystem permissions so MLflow cannot write to executable or persistence-sensitive paths.
• Add WAF or reverse-proxy rules to block traversal payloads targeting MLflow API endpoints as a temporary mitigation, while treating patching as the durable fix.