CVE-2025-10279: Lfprojects Mlflow RCE Vulnerability

CVE-2025-10279 Overview

CVE-2025-10279 is a local privilege escalation vulnerability in MLflow version 2.20.3. The flaw resides in the temporary directory creation logic used for Python virtual environments. MLflow assigns world-writable permissions (0o777) to the directory, allowing any local user with access to /tmp to modify its contents. An attacker can exploit a race condition to overwrite .py files staged in the virtual environment before MLflow executes them. Successful exploitation results in arbitrary code execution under the MLflow process owner. The issue is tracked under [CWE-379: Creation of Temporary File in Directory with Insecure Permissions] and was fixed in MLflow version 3.4.0.

Critical Impact

Local attackers with write access to /tmp can hijack Python virtual environment files to achieve arbitrary code execution as the MLflow user.

Affected Products

• MLflow version 2.20.3 (lfprojects:mlflow)
• Earlier MLflow 2.x versions sharing the same file_utils.py temporary directory logic
• Spark UDF deployments relying on the legacy 0o777 chmod behavior

Discovery Timeline

• 2026-02-02 - CVE-2025-10279 published to NVD
• 2026-04-14 - Last updated in NVD database

Technical Details for CVE-2025-10279

Vulnerability Analysis

MLflow creates temporary directories using tempfile.mkdtemp() for staging Python virtual environments. By default, mkdtemp() returns a directory with 0o700 permissions, restricting access to the owner. To support Spark User Defined Functions (UDFs) that execute across processes, MLflow explicitly relaxed the permissions to 0o777. This change granted read, write, and execute access to every user on the host. Any .py files written into this directory became modifiable by unprivileged users before MLflow loaded them. The vulnerability is local in nature and requires the attacker to win a race against the MLflow runtime.

Root Cause

The root cause is an unnecessary os.chmod(tmp_dir, 0o777) call in mlflow/utils/file_utils.py. The Spark UDF requirement only needed read and execute access for other processes, not write access. The blanket world-writable permission violated the principle of least privilege and exposed the directory contents to tampering.

Attack Vector

An attacker with shell access to the host monitors /tmp for MLflow-created directories. After MLflow stages Python source files for the virtual environment, the attacker overwrites a .py file with malicious code. When MLflow imports or executes the file, the injected code runs in the MLflow process context. The race condition window is narrow but exploitable, particularly on shared compute hosts and multi-tenant ML training environments.

     else:
         tmp_dir = tempfile.mkdtemp()
         # mkdtemp creates a directory with permission 0o700
-        # change it to be 0o777 to ensure it can be seen in spark UDF
-        os.chmod(tmp_dir, 0o777)
+        # For Spark UDFs, we need to make it accessible to other processes
+        # Use 0o750 (owner: rwx, group: r-x, others: None) instead of 0o777
+        # This allows read/execute but not write for group and others
+        os.chmod(tmp_dir, 0o750)
         atexit.register(shutil.rmtree, tmp_dir, ignore_errors=True)
 
     return tmp_dir

Source: GitHub Commit Fix

The patch reduces permissions from 0o777 to 0o750, preserving Spark UDF read/execute access while removing write access for group and others.

Detection Methods for CVE-2025-10279

Indicators of Compromise

• Unexpected modifications to .py files inside MLflow temporary directories under /tmp
• Temporary directories owned by the MLflow user with mode 0o777 permissions
• Python processes spawned by MLflow executing unexpected scripts or making outbound network connections
• File system audit events showing non-MLflow users writing to MLflow tmp directories

Detection Strategies

• Audit file integrity in /tmp directories created by MLflow processes during virtual environment provisioning
• Hunt for chmod 777 operations against MLflow-managed directories using Linux auditd or eBPF telemetry
• Correlate process ancestry to identify Python interpreters spawned by MLflow executing files modified by other users

Monitoring Recommendations

• Enable Linux audit rules on /tmp write events involving .py files inside directories owned by service accounts
• Log MLflow worker process creation and child process execution for anomaly review
• Track inode permission changes on directories created by tempfile.mkdtemp() in MLflow worker contexts

How to Mitigate CVE-2025-10279

Immediate Actions Required

• Upgrade MLflow to version 3.4.0 or later where the temporary directory permissions are restricted to 0o750
• Restrict shell access to hosts running MLflow to trusted operators only
• Run MLflow under a dedicated service account with isolated /tmp namespaces where possible

Patch Information

The fix is committed in GitHub Commit 1d7c8d4 and released in MLflow 3.4.0. The patch modifies mlflow/utils/file_utils.py to use os.chmod(tmp_dir, 0o750) instead of 0o777. Additional context is available in the Huntr Bounty Listing.

Workarounds

• Mount /tmp as a per-user tmpfs to isolate temporary files between accounts using systemd PrivateTmp=yes
• Apply a local patch to mlflow/utils/file_utils.py to override the 0o777 chmod call with 0o750
• Run MLflow inside an unprivileged container so the temporary directory is not shared with other host users

# Apply PrivateTmp isolation via systemd unit override
sudo systemctl edit mlflow.service
# Add the following lines:
# [Service]
# PrivateTmp=yes
sudo systemctl daemon-reload
sudo systemctl restart mlflow.service