Excessive directory permissions in MLflow leads to local privilege escalation when using spark_udf
Description
Excessive directory permissions in MLflow leads to local privilege escalation when using spark_udf. This behavior can be exploited by a local attacker to gain elevated permissions by using a ToCToU attack. The issue is only relevant when the spark_udf() MLflow API is called.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
MLflow's spark_udf creates temporary directories with overly permissive 0o777 permissions, enabling a local attacker to exploit a ToCToU attack for privilege escalation.
Vulnerability
Overview CVE-2024-27134 describes a local privilege escalation in MLflow due to excessive directory permissions when the spark_udf() API is called [1]. The issue stems from the _create_model_downloading_tmp_dir function, which creates temporary directories with mode 0o777, granting read, write, and execute permissions to all local users [2][4].
Exploitation
A local attacker can exploit this through a Time-of-Check Time-of-Use (ToCToU) attack. By racing against the creation of the temporary directory, the attacker can replace or modify files within it before they are used by the MLflow Spark UDF, leading to code execution in the context of the MLflow process [1][3]. The attack requires local access to the system and that the Spark UDF feature is invoked [1].
Impact
Successful exploitation allows the attacker to escalate privileges locally, potentially gaining the same permissions as the user running the MLflow Spark UDF [1]. This can lead to unauthorized data access, modification, or further system compromise.
Mitigation
The fix, introduced in pull request #10874, changes the directory permissions from 0o777 to 0o770, removing global write access [3][4]. Users should update MLflow to a version that includes this commit or apply the patch manually.
- NVD - CVE-2024-27134
- GitHub - mlflow/mlflow: The open source AI engineering platform for agents, LLMs, and ML models. MLflow enables teams of all sizes to debug, evaluate, monitor, and optimize production-quality AI applications while controlling costs and managing access to models and data.
- Fix: Privilege Escalation in MLflow when using spark_udf by WeichenXu123 · Pull Request #10874 · mlflow/mlflow
- Fix: Privilege Escalation in MLflow when using spark_udf (#10874) · mlflow/mlflow@0b1d995
AI Insight generated on May 20, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected packages
Versions sourced from the GitHub Security Advisory.
| Package | Affected versions | Patched versions |
|---|---|---|
mlflowPyPI | < 2.16.0 | 2.16.0 |
Affected products
4- osv-coords2 versions
< 2.16.0+ 1 more
- (no CPE)range: < 2.16.0
- (no CPE)range: < 2.16.0
Patches
10b1d995d66a6Fix: Privilege Escalation in MLflow when using spark_udf (#10874)
1 file changed · +2 −2
mlflow/pyfunc/__init__.py+2 −2 modified@@ -1320,8 +1320,8 @@ def _create_model_downloading_tmp_dir(should_use_nfs): tmp_model_dir = tempfile.mkdtemp(dir=root_model_cache_dir) # mkdtemp creates a directory with permission 0o700 - # change it to be 0o777 to ensure it can be seen in spark UDF - os.chmod(tmp_model_dir, 0o777) + # change it to be 0o770 to ensure it can be seen in spark UDF + os.chmod(tmp_model_dir, 0o770) return tmp_model_dir
Vulnerability mechanics
Generated on May 9, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
4News mentions
0No linked articles in our index yet.