AI Threat Alert
CVE-2024-37059: MLflow: RCE via malicious PyTorch model deserialization
GHSA-wf7f-8fxf-xfxc HIGH PoC AVAILABLEAny MLflow deployment from v0.5.0 through v3.4.0 is vulnerable to RCE if users load PyTorch models from untrusted sources — which is standard workflow in shared model registries. Patch MLflow immediately and implement model provenance controls (signing, restricted upload access). Until patched, treat your MLflow model registry as a critical attack surface requiring the same controls as a production code repository.
What is the risk?
High risk for organizations with shared MLflow model registries. CVSS 8.8 reflects a network-accessible attack with low complexity and full C/I/A impact triad. EPSS is low (0.44%) but this understates real-world exposure: exploitation requires only that a legitimate user loads a model, a routine and often automated action in ML workflows. The attack is trivially executable using well-known Python pickle exploits wrapped in a PyTorch model file. Organizations where multiple teams share a model registry, or where external models are imported into pipelines, face elevated and often unmonitored exposure.
What systems are affected?
How severe is it?
What is the attack surface?
What should I do?
6 steps-
PATCH
Upgrade MLflow to the version that addresses this CVE. Consult the HiddenLayer advisory (hiddenlayer.com/sai-security-advisory/mlflow-june2024) and MLflow release notes for the exact fixed version.
-
ACCESS CONTROL
Restrict model upload permissions in the MLflow registry to trusted service accounts only. Treat model publishing like code merges — require review.
-
MODEL SIGNING
Implement model signing and integrity verification before any model is loaded in shared or production environments.
-
AUDIT
Enumerate all PyTorch models uploaded to your MLflow registry and validate their provenance and upload source.
-
DETECTION
Monitor for unexpected process spawning, outbound network connections, or file writes triggered during model loading operations. Alert on mlflow load events from unexpected principals or at anomalous times.
-
WORKAROUND (if patching is delayed): Restrict PyTorch model loading to models uploaded by verified internal sources only; consider using format restrictions or a dedicated isolated environment for loading externally-sourced models.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2024-37059?
Any MLflow deployment from v0.5.0 through v3.4.0 is vulnerable to RCE if users load PyTorch models from untrusted sources — which is standard workflow in shared model registries. Patch MLflow immediately and implement model provenance controls (signing, restricted upload access). Until patched, treat your MLflow model registry as a critical attack surface requiring the same controls as a production code repository.
Is CVE-2024-37059 actively exploited?
Proof-of-concept exploit code is publicly available for CVE-2024-37059, increasing the risk of exploitation.
How to fix CVE-2024-37059?
1. PATCH: Upgrade MLflow to the version that addresses this CVE. Consult the HiddenLayer advisory (hiddenlayer.com/sai-security-advisory/mlflow-june2024) and MLflow release notes for the exact fixed version. 2. ACCESS CONTROL: Restrict model upload permissions in the MLflow registry to trusted service accounts only. Treat model publishing like code merges — require review. 3. MODEL SIGNING: Implement model signing and integrity verification before any model is loaded in shared or production environments. 4. AUDIT: Enumerate all PyTorch models uploaded to your MLflow registry and validate their provenance and upload source. 5. DETECTION: Monitor for unexpected process spawning, outbound network connections, or file writes triggered during model loading operations. Alert on mlflow load events from unexpected principals or at anomalous times. 6. WORKAROUND (if patching is delayed): Restrict PyTorch model loading to models uploaded by verified internal sources only; consider using format restrictions or a dedicated isolated environment for loading externally-sourced models.
What systems are affected by CVE-2024-37059?
This vulnerability affects the following AI/ML architecture patterns: model registries, training pipelines, MLOps pipelines, model serving, CI/CD for ML.
What is the CVSS score for CVE-2024-37059?
CVE-2024-37059 has a CVSS v3.1 base score of 8.8 (HIGH). The EPSS exploitation probability is 0.62%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0010.003 Model AML.T0011.000 Unsafe AI Artifacts AML.T0018.002 Embed Malware AML.T0058 Publish Poisoned Models Compliance Controls Affected
What are the technical details?
Original Advisory
Deserialization of untrusted data can occur in versions of the MLflow platform running version 0.5.0 or newer, enabling a maliciously uploaded PyTorch model to run arbitrary code on an end user’s system when interacted with.
Exploitation Scenario
An attacker gains write access to a shared MLflow model registry — through stolen developer credentials, a compromised CI/CD service account, or by targeting an MLflow instance exposed without proper authentication. They craft a malicious PyTorch model file where the serialized pickle payload contains a reverse shell or credential harvesting payload embedded via Python's __reduce__ mechanism. The model is uploaded with a legitimate-sounding name such as 'bert-classifier-v3' or 'production-nlp-latest'. When a data scientist runs standard evaluation code (mlflow.pytorch.load_model('models:/bert-classifier-v3/Production')), deserialization triggers RCE in their environment. From this foothold, the attacker exfiltrates cloud credentials, training data, API keys stored in environment variables, pivots to internal infrastructure, or poisons subsequent training runs to create a persistent backdoor in production models.
Weaknesses (CWE)
CWE-502 Deserialization of Untrusted Data
Primary
CWE-502 Deserialization of Untrusted Data
Primary
CWE-502 Deserialization of Untrusted Data CWE-502 — Deserialization of Untrusted Data: The product deserializes untrusted data without sufficiently ensuring that the resulting data will be valid.
- [Architecture and Design, Implementation] If available, use the signing/sealing features of the programming language to assure that deserialized data has not been tainted. For example, a hash-based message authentication code (HMAC) could be used to ensure that data has not been modified.
- [Implementation] When deserializing data, populate a new object rather than just deserializing. The result is that the data flows through safe input validation and that the functions are safe.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H References
Timeline
Related Vulnerabilities
CVE-2025-15379 10.0 MLflow: RCE via unsanitized model dependency specs
Same package: mlflow CVE-2023-3765 10.0 MLflow: path traversal allows arbitrary file read
Same package: mlflow CVE-2026-2635 9.8 mlflow: security flaw enables exploitation
Same package: mlflow CVE-2023-1177 9.8 MLflow: path traversal allows arbitrary file read/write
Same package: mlflow CVE-2023-2780 9.8 MLflow: path traversal allows arbitrary file read/write
Same package: mlflow