CVE-2026-4137: MLflow insecure tmp dir perms enable

Q: Is CVE-2026-4137 actively exploited?

No confirmed active exploitation of CVE-2026-4137 has been reported, but organizations should still patch proactively.

Q: How to fix CVE-2026-4137?

1. Upgrade MLflow to 3.11.0 — commit 1dcbb0c2fbd1f446c328830e601ca13a28219b8a applies the fix. 2. On shared environments, enforce a restrictive umask (0022 or stricter) for all MLflow processes. 3. Audit NFS-mounted tmp directories: `find /tmp -type d -perm -o+w -ls` — any world-writable directory reachable by MLflow is a risk surface. 4. Restrict NFS mount permissions and enforce per-user tmp directory isolation at the OS or container level. 5. Monitor for unexpected file modifications in MLflow temp paths using inotify or equivalent. 6. If immediate upgrade is not possible, consider disabling NFS-backed tmp directories or restricting the MLflow process to a dedicated, non-shared user account.

Q: What systems are affected by CVE-2026-4137?

This vulnerability affects the following AI/ML architecture patterns: model serving, training pipelines, MLOps CI/CD pipelines, shared NFS ML environments, ML experiment tracking.

Q: What is the CVSS score for CVE-2026-4137?

CVE-2026-4137 has a CVSS v3.1 base score of 7.0 (HIGH). The EPSS exploitation probability is 0.19%.

CISO Take

MLflow before 3.11.0 creates model-download temp directories with world-writable (0o777) or group-writable (0o770) permissions, allowing any local user to swap out cloudpickle-serialized model artifacts before deserialization — yielding arbitrary code execution under the MLflow process. The blast radius is highest in Databricks and shared NFS environments where these paths span multiple users and workloads, and the exploitation primitive requires no special tooling beyond local filesystem access. This is a second pass at the same vulnerability class as CVE-2025-10279, meaning the original fix was incomplete and any attacker familiar with the prior CVE knows exactly where to look. No public exploit or KEV listing exists yet, but the attack is trivial once local access is established. Upgrade to MLflow 3.11.0 immediately and audit NFS-mounted tmp directories for world-writable paths (`find /tmp -type d -perm -o+w`) as an interim check.

Sources: NVD GitHub Advisory ATLAS

What is the risk?

Despite a local attack vector, the risk profile is elevated for any organization running MLflow on shared infrastructure — particularly Databricks, where NFS is on by default and the vulnerable tmp paths are reachable across workspace users. The deserialization-to-RCE chain via cloudpickle is well-understood, reliable, and requires no AI/ML expertise to weaponize. The incomplete-fix lineage (bypassing CVE-2025-10279) signals that the root cause was not fully addressed upstream, raising the likelihood of further variants. Rate this HIGH in multi-tenant cloud ML environments, MEDIUM in single-user local development setups.

How does the attack unfold?

Local Access

Attacker obtains local access to a shared compute environment — such as a Databricks workspace or shared HPC node — with read/write access to NFS mounts used by MLflow for model staging.

AML.T0012

Artifact Discovery

Attacker identifies the world-writable (0o777) MLflow NFS tmp directory by scanning for writable paths, then monitors filesystem activity to detect when a target model download begins.

AML.T0035

Artifact Tampering

Attacker replaces the legitimate cloudpickle-serialized model file in the writable tmp directory with a malicious payload embedding arbitrary OS commands before the victim process completes its download.

AML.T0018.002

Code Execution

Victim's MLflow process calls cloudpickle.load() on the tampered artifact, executing the attacker's payload in the victim's process context with full access to ML environment credentials, datasets, and cloud resources.

AML.T0112.001

Local Access

Attacker obtains local access to a shared compute environment — such as a Databricks workspace or shared HPC node — with read/write access to NFS mounts used by MLflow for model staging.

AML.T0012

Artifact Discovery

Attacker identifies the world-writable (0o777) MLflow NFS tmp directory by scanning for writable paths, then monitors filesystem activity to detect when a target model download begins.

AML.T0035

Artifact Tampering

Attacker replaces the legitimate cloudpickle-serialized model file in the writable tmp directory with a malicious payload embedding arbitrary OS commands before the victim process completes its download.

AML.T0018.002

Code Execution

Victim's MLflow process calls cloudpickle.load() on the tampered artifact, executing the attacker's payload in the victim's process context with full access to ML environment credentials, datasets, and cloud resources.

AML.T0112.001

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
MLflow	pip	< 3.11.0	`3.11.0`
26.7K OpenSSF 5.4 655 dependents Pushed 6d ago 31% patched ~76d to patch Full package profile →

Do you use MLflow? You're affected.

How severe is it?

CVSS 3.1

7.0 / 10

EPSS

0.2%

chance of exploitation in 30 days

Higher than 9% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Trivial

Exploitation Confidence

medium

○ CISA SSVC: Public PoC

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV Local

AC High

PR Low

UI None

S Unchanged

C High

I High

A High

What should I do?

6 steps

Upgrade MLflow to 3.11.0 — commit 1dcbb0c2fbd1f446c328830e601ca13a28219b8a applies the fix.
On shared environments, enforce a restrictive umask (0022 or stricter) for all MLflow processes.
Audit NFS-mounted tmp directories: find /tmp -type d -perm -o+w -ls — any world-writable directory reachable by MLflow is a risk surface.
Restrict NFS mount permissions and enforce per-user tmp directory isolation at the OS or container level.
Monitor for unexpected file modifications in MLflow temp paths using inotify or equivalent.
If immediate upgrade is not possible, consider disabling NFS-backed tmp directories or restricting the MLflow process to a dedicated, non-shared user account.

What does CISA's SSVC say?

Decision Attend

Exploitation poc

Automatable No

Technical Impact total

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Code Execution Supply Chain Framework Model AML.T0010.001 - AI Software AML.T0011.000 - Unsafe AI Artifacts AML.T0018.002 - Embed Malware AML.T0112.001 - AI Artifacts

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art. 15 - Accuracy, robustness and cybersecurity

ISO 42001

Clause 8.4 - AI system operation and monitoring

NIST AI RMF

MANAGE 2.2 - Mechanisms to sustain AI risk management

OWASP LLM Top 10

LLM03:2025 - Supply Chain

Frequently Asked Questions

What is CVE-2026-4137?

MLflow before 3.11.0 creates model-download temp directories with world-writable (0o777) or group-writable (0o770) permissions, allowing any local user to swap out cloudpickle-serialized model artifacts before deserialization — yielding arbitrary code execution under the MLflow process. The blast radius is highest in Databricks and shared NFS environments where these paths span multiple users and workloads, and the exploitation primitive requires no special tooling beyond local filesystem access. This is a second pass at the same vulnerability class as CVE-2025-10279, meaning the original fix was incomplete and any attacker familiar with the prior CVE knows exactly where to look. No public exploit or KEV listing exists yet, but the attack is trivial once local access is established. Upgrade to MLflow 3.11.0 immediately and audit NFS-mounted tmp directories for world-writable paths (`find /tmp -type d -perm -o+w`) as an interim check.

Is CVE-2026-4137 actively exploited?

No confirmed active exploitation of CVE-2026-4137 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-4137?

1. Upgrade MLflow to 3.11.0 — commit 1dcbb0c2fbd1f446c328830e601ca13a28219b8a applies the fix. 2. On shared environments, enforce a restrictive umask (0022 or stricter) for all MLflow processes. 3. Audit NFS-mounted tmp directories: `find /tmp -type d -perm -o+w -ls` — any world-writable directory reachable by MLflow is a risk surface. 4. Restrict NFS mount permissions and enforce per-user tmp directory isolation at the OS or container level. 5. Monitor for unexpected file modifications in MLflow temp paths using inotify or equivalent. 6. If immediate upgrade is not possible, consider disabling NFS-backed tmp directories or restricting the MLflow process to a dedicated, non-shared user account.

What systems are affected by CVE-2026-4137?

This vulnerability affects the following AI/ML architecture patterns: model serving, training pipelines, MLOps CI/CD pipelines, shared NFS ML environments, ML experiment tracking.

What is the CVSS score for CVE-2026-4137?

CVE-2026-4137 has a CVSS v3.1 base score of 7.0 (HIGH). The EPSS exploitation probability is 0.19%.

What is the AI security impact?

Affected AI Architectures

model servingtraining pipelinesMLOps CI/CD pipelinesshared NFS ML environmentsML experiment tracking

MITRE ATLAS Techniques

AML.T0010.001 AI Software

AML.T0011.000 Unsafe AI Artifacts

AML.T0018.002 Embed Malware

AML.T0112.001 AI Artifacts

Compliance Controls Affected

EU AI Act: Art. 15

ISO 42001: Clause 8.4

NIST AI RMF: MANAGE 2.2

OWASP LLM Top 10: LLM03:2025

What are the technical details?

Original Advisory

In mlflow/mlflow versions prior to 3.11.0, the `get_or_create_nfs_tmp_dir()` function in `mlflow/utils/file_utils.py` creates temporary directories with world-writable permissions (0o777), and the `_create_model_downloading_tmp_dir()` function in `mlflow/pyfunc/__init__.py` creates directories with group-writable permissions (0o770). These insecure permissions allow local attackers to tamper with model artifacts, such as cloudpickle-serialized Python objects, and achieve arbitrary code execution when the tampered artifacts are deserialized via `cloudpickle.load()`. This vulnerability is particularly critical in environments with shared NFS mounts, such as Databricks, where NFS is enabled by default. The issue is a continuation of the vulnerability class addressed in CVE-2025-10279, which was only partially fixed.

Exploitation Scenario

An attacker with local access to a shared Databricks workspace watches the NFS-mounted tmp directory used by MLflow's model download code. When a legitimate user triggers a model load — such as a scheduled retraining job or a serving container restart — the attacker rapidly replaces the staged cloudpickle-serialized model artifact with a malicious payload before `cloudpickle.load()` is called. The victim's MLflow process deserializes the tampered file, executing the attacker's code with full access to the ML environment's credentials, datasets, and downstream systems. The race window is wide in environments where model downloads are slow over NFS, making reliable exploitation straightforward.

Weaknesses (CWE)

CWE-378 Creation of Temporary File With Insecure Permissions Primary CWE-378 Creation of Temporary File With Insecure Permissions Primary

CWE-378 — Creation of Temporary File With Insecure Permissions: Opening temporary files without appropriate measures or controls can leave the file, its contents and any function that it impacts vulnerable to attack.

[Requirements] Many contemporary languages have functions which properly handle this condition. Older C temp file functions are especially susceptible.
[Implementation] Ensure that you use proper file permissions. This can be achieved by using a safe temp file function. Temporary files should be writable and readable only by the process that owns the file.

Source: MITRE CWE corpus.