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

CVE-2026-4137 has a CVSS 3.1 base score of 7.8 (High). CVSS vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.0%.

Which versions of MLflow are affected by CVE-2026-4137?

MLflow prior to version 3.11.0 allows local users with filesystem access to execute arbitrary code through insecure temporary directory permissions and model artifact deserialization, with particular…. A patch is available.

How to fix or mitigate CVE-2026-4137?

Within 24 hours: Identify all MLflow deployments and document current versions in use. Within 7 days: Upgrade all MLflow instances to version 3.11.0 or later and validate deployment compatibility. Within 30 days: Audit filesystem permissions on MLflow directories to ensure temporary directories are not world-writable (remove 0o777 and 0o770 permissions) and implement monitoring for unauthorized artifact modifications.

MLflow CVE-2026-4137

EUVD-2026-30807 HIGH

Creation of Temporary File With Insecure Permissions (CWE-378)

2026-05-18 @huntr_ai

GHSA-f2m9-wcf4-cwwx

Python RCE

7.8

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

7.8 HIGH

AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Primary rating from NVD · only source for this CVE.

CVSS VectorNVD

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Attack Vector

Local

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Updated

Jun 02, 2026 - 20:29 vuln.today

v3 (cvss_changed)

Analysis Updated

Jun 02, 2026 - 20:29 vuln.today

v2 (cvss_changed)

Re-analysis Queued

Jun 02, 2026 - 20:22 vuln.today

cvss_changed

CVSS changed

Jun 02, 2026 - 20:22 NVD

7.0 (HIGH) 7.8 (HIGH)

Source Code Evidence Fetched

May 18, 2026 - 21:31 vuln.today

Analysis Generated

May 18, 2026 - 21:31 vuln.today

Patch available

May 18, 2026 - 21:09 EUVD

DescriptionCVE.org

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.

AnalysisAI

Local privilege escalation to arbitrary code execution in MLflow versions prior to 3.11.0 stems from insecure temporary directory permissions (0o777 and 0o770) created by NFS and model-download helpers. Any local user sharing the filesystem - particularly on Databricks where NFS is enabled by default - can overwrite cloudpickle-serialized model artifacts and gain code execution when another user's process deserializes them via cloudpickle.load(). No public exploit is identified at time of analysis, and the issue is a continuation of CVE-2025-10279 which was only partially fixed.

Technical ContextAI

MLflow is an open-source ML lifecycle platform that stages model artifacts on disk before serving them through pyfunc loaders. The vulnerable helpers get_or_create_nfs_tmp_dir() in mlflow/utils/file_utils.py and _create_model_downloading_tmp_dir() in mlflow/pyfunc/__init__.py explicitly chmod their staging directories to 0o777 (world rwx) and 0o770 (group rwx) respectively so Spark UDF worker processes can read them. This maps to CWE-378 (Creation of Temporary File With Insecure Permissions): because cloudpickle.load() executes arbitrary __reduce__ payloads embedded in a pickle stream, any attacker with write access to the staging directory can substitute a malicious pickle, and the next deserialization by the victim process runs attacker code with the victim's privileges. The upstream fix tightens both paths to 0o750, preserving group read/execute (needed for Spark UDFs) while removing group and world write.

RemediationAI

Vendor-released patch: upgrade to MLflow 3.11.0 or later, which restricts the NFS staging directory and the pyfunc model-downloading temp directory to mode 0o750 (owner rwx, group rx, others none) per commit 1dcbb0c2fbd1f446c328830e601ca13a28219b8a. Where immediate upgrade is not possible, manually run chmod 750 (or stricter, e.g. 700 if Spark UDFs are not in use) against the existing NFS tmp directory and the pyfunc model-downloading tmp directory after MLflow creates them - note that 700 will break Spark UDF workers that run as a different group, while 750 preserves UDF compatibility. As a deployment-level control, dedicate the NFS mount to a single tenant or restrict access to a trusted group via mount options and POSIX ACLs so untrusted local users cannot write into the staging path, and avoid loading models from any directory writable by other principals. Reference the huntr report (https://huntr.com/bounties/648dc30b-76c7-4433-86b8-f43d926fd8d6) and the NVD entry (https://nvd.nist.gov/vuln/detail/CVE-2026-4137) for advisory tracking.