MLflow's insecure /tmp directory permissions (0o777) during venv creation expose training pipelines to local code execution via race condition. Any shared compute environment — Jupyter hubs, multi-tenant GPU clusters, or containerized ML platforms without proper namespace isolation — is at risk. Patch to MLflow 3.4.0 immediately; if you can't patch today, restrict /tmp access with sticky bits and audit shared MLflow deployments.
Risk Assessment
Real-world risk is moderate despite the High CVSS score. Exploitation requires local access and successful race condition timing (high complexity), limiting remote attack surface. However, shared ML infrastructure is the norm in enterprise AI — data scientists on Jupyter Hub, shared Slurm/Kubernetes GPU nodes, and CI/CD ML pipelines all create multi-tenant /tmp environments where this becomes practically exploitable. EPSS of 0.00007 confirms no current active exploitation, but the attack primitive is well-understood and tooling for race condition exploits is widely available.
Affected Systems
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| mlflow | pip | < 3.4.0rc0 | 3.4.0rc0 |
Do you use mlflow? You're affected.
Severity & Risk
Attack Surface
Recommended Action
5 steps-
PATCH
Upgrade MLflow to >= 3.4.0 — the fix applies secure permissions to temp directories during venv creation.
-
WORKAROUND (if immediate patch is not possible): Set sticky bit on /tmp (chmod +t /tmp) to prevent non-owners from deleting/overwriting others' files; use private temp directories via TMPDIR env var pointing to user-owned paths.
-
ISOLATE
Run MLflow training jobs in dedicated containers or VMs with non-shared /tmp filesystems — this eliminates the attack surface entirely.
-
DETECT
Monitor for unexpected writes to /tmp/*/.venv/ or /tmp/*/lib/python*/site-packages/ by processes other than mlflow; alert on mlflow process loading .py files from /tmp after a write by a different UID.
-
AUDIT
Inventory all MLflow deployments, especially shared Jupyter/Slurm environments with multiple user accounts.
CISA SSVC Assessment
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
Classification
Compliance Impact
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2025-10279?
MLflow's insecure /tmp directory permissions (0o777) during venv creation expose training pipelines to local code execution via race condition. Any shared compute environment — Jupyter hubs, multi-tenant GPU clusters, or containerized ML platforms without proper namespace isolation — is at risk. Patch to MLflow 3.4.0 immediately; if you can't patch today, restrict /tmp access with sticky bits and audit shared MLflow deployments.
Is CVE-2025-10279 actively exploited?
No confirmed active exploitation of CVE-2025-10279 has been reported, but organizations should still patch proactively.
How to fix CVE-2025-10279?
1. PATCH: Upgrade MLflow to >= 3.4.0 — the fix applies secure permissions to temp directories during venv creation. 2. WORKAROUND (if immediate patch is not possible): Set sticky bit on /tmp (chmod +t /tmp) to prevent non-owners from deleting/overwriting others' files; use private temp directories via TMPDIR env var pointing to user-owned paths. 3. ISOLATE: Run MLflow training jobs in dedicated containers or VMs with non-shared /tmp filesystems — this eliminates the attack surface entirely. 4. DETECT: Monitor for unexpected writes to /tmp/*/.venv/ or /tmp/*/lib/python*/site-packages/ by processes other than mlflow; alert on mlflow process loading .py files from /tmp after a write by a different UID. 5. AUDIT: Inventory all MLflow deployments, especially shared Jupyter/Slurm environments with multiple user accounts.
What systems are affected by CVE-2025-10279?
This vulnerability affects the following AI/ML architecture patterns: training pipelines, ML experiment tracking, model registry, MLOps platforms, shared compute clusters.
What is the CVSS score for CVE-2025-10279?
CVE-2025-10279 has a CVSS v3.1 base score of 7.0 (HIGH). The EPSS exploitation probability is 0.01%.
Technical Details
NVD Description
In mlflow version 2.20.3, the temporary directory used for creating Python virtual environments is assigned insecure world-writable permissions (0o777). This vulnerability allows an attacker with write access to the `/tmp` directory to exploit a race condition and overwrite `.py` files in the virtual environment, leading to arbitrary code execution. The issue is resolved in version 3.4.0.
Exploitation Scenario
On a shared GPU cluster where 20 data scientists run MLflow experiments, an adversary with a low-privilege shell account monitors inotify events on /tmp watching for MLflow venv directory creation. When MLflow creates /tmp/mlflow-venv-XXXX/ with 0o777 permissions, the attacker has a brief window to overwrite a commonly imported .py file (e.g., site.py, importlib bootstrap) with a malicious payload before MLflow's Python interpreter executes it. The injected code runs in the MLflow process context, harvesting AWS/GCP credentials from environment variables, exfiltrating model artifacts from the registry, and optionally modifying model weights before they're logged — a silent supply chain attack on the ML pipeline that produces poisoned models deployed to production.
Weaknesses (CWE)
CVSS Vector
CVSS:3.0/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H References
Timeline
Related Vulnerabilities
CVE-2025-15379 10.0 MLflow: RCE via unsanitized model dependency specs
Same package: mlflow CVE-2023-3765 10.0 MLflow: path traversal allows arbitrary file read
Same package: mlflow CVE-2026-2635 9.8 mlflow: security flaw enables exploitation
Same package: mlflow CVE-2023-2780 9.8 MLflow: path traversal allows arbitrary file read/write
Same package: mlflow CVE-2023-1177 9.8 MLflow: path traversal allows arbitrary file read/write
Same package: mlflow
AI Threat Alert