CVE-2025-10279

What it actually does

MLflow 2.20.3 creates temporary Python virtual environment directories with world-writable permissions, such as mode 0777. A low-privileged local attacker or co-resident process that can write to the shared temporary directory can race MLflow during virtual environment creation and overwrite Python source files inside the environment. When MLflow later imports or executes those files, attacker-controlled Python code can run with the privileges of the MLflow process. The CVSS vector indicates local access, low privileges, high attack complexity, no user interaction, and potential full confidentiality, integrity, and availability impact within the affected process context.

Why it matters to the business

If exploited, this flaw can let an attacker who already has limited local access turn that access into code execution under an MLflow workload, which can expose model artifacts, credentials, experiment data, pipeline secrets, or compute resources. The risk is highest on shared hosts, multi-user build systems, notebooks, CI runners, containers sharing a writable temporary filesystem, or ML platforms where untrusted users can run code near MLflow processes. It is not listed in CISA KEV, has no reported exploit maturity in the provided data, and has a low EPSS score, so broad internet-scale exploitation is less likely; however, the business impact can still be severe in shared ML or DevOps environments because exploitation can compromise the integrity of model training, evaluation, or deployment workflows.

How an attack unfolds

An attacker first obtains low-privileged local execution on a system where vulnerable MLflow code creates Python virtual environments using a shared temporary directory. The attacker watches the temporary directory for new MLflow-created virtual environment paths with permissive 0777 permissions. During the short window while the environment is being created, the attacker writes to or replaces Python .py files in that virtual environment, targeting files likely to be imported or executed by MLflow or by the Python runtime. When MLflow subsequently activates or uses the virtual environment, the modified Python file is executed in the context of the MLflow process. The attacker’s payload can then read accessible files, exfiltrate secrets, modify model artifacts, tamper with experiment results, spawn processes, or establish persistence consistent with the privileges and sandbox boundaries of the MLflow runtime.

How to fix it

Upgrade MLflow to version 3.4.0 or later, or apply the upstream fix commit 1d7c8d4cf0a67d407499a8a4ffac387ea4f8194a where source-based deployment is used. For affected MinimOS GitLab FIPS packages, upgrade to the fixed package releases: gitlab-cng-fips-18.5 18.5.2-r0, gitlab-base-fips-18.5 18.5.2-r0, gitlab-container-registry-fips-18.5 18.5.2-r0, gitlab-logger-fips-18.5 18.5.2-r0, and gitlab-shell-fips-18.5 18.5.2-r0. As compensating controls until patching is complete, avoid running vulnerable MLflow versions on shared multi-user hosts; isolate MLflow workloads per user or per container; ensure temporary directories used by MLflow are private to the service account and not world-writable; set TMPDIR, TEMP, and TMP to directories owned by the MLflow runtime user with mode 0700; mount temporary filesystems with restrictive options where operationally feasible; and restrict untrusted local shell or notebook access on systems running MLflow.

How to confirm the fix worked

Confirm the installed MLflow version with package inventory tools such as pip show mlflow, python -c 'import mlflow; print(mlflow.__version__)', container image manifests, SBOMs, or dependency lockfiles, and verify that it is 3.4.0 or later or contains commit 1d7c8d4cf0a67d407499a8a4ffac387ea4f8194a. For MinimOS GitLab FIPS images or packages, verify the installed package versions are 18.5.2-r0 or later for the affected components. Validate runtime behavior by checking that MLflow-created temporary virtual environment directories are not world-writable and are owned only by the MLflow runtime identity, preferably with permissions such as 0700. Review container images and build artifacts to ensure vulnerable MLflow 2.20.3 is not present in transitive dependencies. Confirm environment variables such as TMPDIR, TEMP, and TMP point to private, restricted directories for MLflow services, jobs, and notebooks.

Typical attack path

1. Gain low-privileged local execution on a host, container, CI runner, notebook server, or shared ML environment that runs vulnerable MLflow functionality.
2. Monitor the shared temporary directory, commonly /tmp, for creation of MLflow-related Python virtual environment directories.
3. Identify virtual environment directories created with world-writable permissions such as 0777.
4. Race the virtual environment creation process and overwrite or replace Python .py files inside the environment before MLflow imports them.
5. Wait for MLflow or Python to import or execute the modified file.
6. Run attacker-controlled code with the privileges of the MLflow process.
7. Use that execution context to access MLflow artifacts, credentials, datasets, model files, logs, network resources, or downstream pipeline components.

How to detect it

To determine whether exploitation already occurred, examine host and container telemetry around MLflow job execution times. Focus on Linux audit logs, EDR file modification telemetry, process creation logs, shell histories, container runtime logs, MLflow service logs, notebook execution logs, and CI runner logs. Look for non-MLflow users or unexpected processes writing, replacing, or changing permissions on .py files inside temporary Python virtual environment directories under shared temporary paths such as /tmp. Correlate those writes with subsequent Python or MLflow process execution, imports from the same directory, or unexpected child processes such as shells, network utilities, package managers, or credential-access commands launched by the MLflow runtime. Investigate any world-writable virtual environment directories, symlinks, recently modified Python files in temporary environments, unusual file owners, or timestamps showing .py files changed after environment creation but before MLflow execution. Also review MLflow artifact stores, model registry activity, credentials, and outbound network logs for follow-on access or exfiltration. There are no public threat actors or KEV exploitation details in the provided data, so detection should be behavior-based rather than actor-specific.

• MLflow version 2.20.3
• mlflow==2.20.3
• /tmp
• drwxrwxrwx
• 0777
• 0o777
• TMPDIR=/tmp
• TEMP=/tmp
• TMP=/tmp
• .py files modified under /tmp
• python virtual environment directory with mode 777
• unexpected .py ownership under /tmp
• python process executing from /tmp
• mlflow process spawning /bin/sh
• mlflow process spawning /bin/bash
• mlflow process spawning curl
• mlflow process spawning wget
• mlflow process spawning nc
• mlflow process spawning python from /tmp

What your security team should do

• Prioritize patching MLflow 2.20.3 to 3.4.0 or later on shared ML platforms, notebook servers, CI runners, and any environment where multiple users or workloads can write to the same temporary directory.
• Inventory containers, virtual environments, notebooks, model-serving images, CI images, and GitLab FIPS MinimOS packages for vulnerable MLflow versions or affected package versions.
• Harden MLflow runtime configuration by assigning a private temporary directory with 0700 permissions for each service, job, user, or container.
• Restrict local access to systems running vulnerable MLflow, especially untrusted shell access, shared notebooks, and co-resident containers that share /tmp.
• Enable or tune EDR, auditd, or file-integrity monitoring for writes to Python files under temporary virtual environment paths and for unexpected child processes spawned by MLflow or Python.
• Review recent MLflow job execution logs, system audit logs, shell histories, and process telemetry for evidence of suspicious writes to /tmp followed by execution from modified virtual environments.
• Treat unexpected changes to model artifacts, experiment metadata, pipeline outputs, or credentials accessible to MLflow as potential post-exploitation activity until ruled out.