CVE-2026-4137 — AWAITING NVD

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.

Attack Kill Chain

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	—	No patch
26.0K OpenSSF 4.6 636 dependents Pushed 3d ago 26% patched ~58d to patch Full package profile →

Do you use mlflow? You're affected.

Severity & Risk

CVSS 3.1

N/A

EPSS

0.0%

chance of exploitation in 30 days

Higher than 0% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

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.

Classification

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

Compliance Impact

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?

No CVSS score has been assigned yet.

Technical Details

NVD Description

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.