AI Threat AlertCVE-2026-96804: MLflow: pickle deserialization RCE in statsmodels flavor
HIGHMLflow's statsmodels model flavor (versions 2.1.0 through 3.14.0) loads models via pickle without honoring the MLFLOW_ALLOW_PICKLE_DESERIALIZATION=False safeguard, so a crafted MLmodel artifact executes arbitrary code on whoever loads it. The CVSS is 8.8 with network reach, low complexity and low privileges, meaning anyone who can register or upload a model to a shared tracking server or registry can reach code execution on the consumers. Near-term exploitation pressure looks modest: EPSS is 0.00423 (65th percentile), it is not in CISA KEV, no public exploit or Nuclei template exists, and SSVC says TRACK. Even so, MLflow sits at the center of many MLOps estates, so a poisoned model could land on training hosts and serving nodes that hold cloud credentials and data access. Upgrade to a fixed MLflow release once the vendor publishes one (consult the CERT/CC note VU#369093), and until then do not load statsmodels models from untrusted or unreviewed sources.
What is the risk?
Medium-high. Impact is complete (C:H/I:H/A:H) and the attack is simple once the adversary can supply an artifact, but it needs low privileges (an account able to log or register models) and a victim who loads the model, since exploitation is not fully unauthenticated or self-propagating. Exploitation likelihood is currently low (EPSS 0.00423, no public exploit, not in KEV, SSVC TRACK). Exposure is driven by how widely model registries are shared across teams or exposed to partners and external contributors. Package risk data (dependents, Scorecard) was unavailable, so blast radius cannot be quantified.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| MLflow | pip | — | No patch |
Do you use MLflow? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 step1) Inventory MLflow versions between 2.1.0 and 3.14.0 and identify any use of the statsmodels flavor (look for 'statsmodels' in MLmodel files and mlflow.statsmodels.load_model calls). 2) Upgrade to the vendor-fixed release when available; check the CERT/CC advisory (VU#369093) and the MLflow release notes. 3) Until patched, restrict who can log or register models, require review/approval for registry stage transitions, and block loading of statsmodels models from unvetted sources. 4) Run model loading and serving in sandboxed, least-privilege containers with no long-lived cloud credentials and restricted egress. 5) Scan model artifacts with pickle scanners (picklescan, fickling) and verify artifact provenance or signatures. 6) Detect: alert on unexpected child processes, outbound connections or file writes from MLflow worker, scoring and notebook processes, and audit registry events for new statsmodels models from unusual users.
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-2026-96804?
MLflow's statsmodels model flavor (versions 2.1.0 through 3.14.0) loads models via pickle without honoring the MLFLOW_ALLOW_PICKLE_DESERIALIZATION=False safeguard, so a crafted MLmodel artifact executes arbitrary code on whoever loads it. The CVSS is 8.8 with network reach, low complexity and low privileges, meaning anyone who can register or upload a model to a shared tracking server or registry can reach code execution on the consumers. Near-term exploitation pressure looks modest: EPSS is 0.00423 (65th percentile), it is not in CISA KEV, no public exploit or Nuclei template exists, and SSVC says TRACK. Even so, MLflow sits at the center of many MLOps estates, so a poisoned model could land on training hosts and serving nodes that hold cloud credentials and data access. Upgrade to a fixed MLflow release once the vendor publishes one (consult the CERT/CC note VU#369093), and until then do not load statsmodels models from untrusted or unreviewed sources.
Is CVE-2026-96804 actively exploited?
No confirmed active exploitation of CVE-2026-96804 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-96804?
1) Inventory MLflow versions between 2.1.0 and 3.14.0 and identify any use of the statsmodels flavor (look for 'statsmodels' in MLmodel files and mlflow.statsmodels.load_model calls). 2) Upgrade to the vendor-fixed release when available; check the CERT/CC advisory (VU#369093) and the MLflow release notes. 3) Until patched, restrict who can log or register models, require review/approval for registry stage transitions, and block loading of statsmodels models from unvetted sources. 4) Run model loading and serving in sandboxed, least-privilege containers with no long-lived cloud credentials and restricted egress. 5) Scan model artifacts with pickle scanners (picklescan, fickling) and verify artifact provenance or signatures. 6) Detect: alert on unexpected child processes, outbound connections or file writes from MLflow worker, scoring and notebook processes, and audit registry events for new statsmodels models from unusual users.
What systems are affected by CVE-2026-96804?
This vulnerability affects the following AI/ML architecture patterns: MLOps model registries, Model serving, Training pipelines, Batch scoring pipelines, Notebook/data science environments.
What is the CVSS score for CVE-2026-96804?
CVE-2026-96804 has a CVSS v3.1 base score of 8.8 (HIGH). The EPSS exploitation probability is 0.75%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0010.003ModelAML.T0011.000Unsafe AI ArtifactsAML.T0018.002Embed MalwareAML.T0058Publish Poisoned ModelsAML.T0112.001AI ArtifactsCompliance Controls Affected
What are the technical details?
Original Advisory
MLflow's statsmodel flavor, versions 2.1.0 to 3.14.0, omits the MLFLOW_ALLOW_PICKLE_DESERIALIZATION=False security control entirely in _load_model(), which allows a remote attacker to execute arbitrary code via a crafted MLmodel artifact.
Exploitation Scenario
An attacker with a low-privilege account on a shared MLflow tracking server (or a compromised contributor/data scientist account) logs a statsmodels model whose pickled payload contains a malicious __reduce__ routine and a valid-looking MLmodel file. They register it as a new version of a commonly used model. When a teammate, scheduled batch-scoring job or automated promotion pipeline calls the statsmodels load path, the payload runs despite MLFLOW_ALLOW_PICKLE_DESERIALIZATION=False, opening a reverse shell or stealing cloud credentials from the environment. From there the attacker pivots to the artifact store, training data and production serving infrastructure.
Weaknesses (CWE)
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:L/UI:N/S:U/C:H/I:H/A:HReferences
Timeline
Related Vulnerabilities
CVE-2025-1537910.0MLflow: RCE via unsanitized model dependency specs
Same package: mlflowCVE-2023-376510.0MLflow: path traversal allows arbitrary file read
Same package: mlflowCVE-2023-27809.8MLflow: path traversal allows arbitrary file read/write
Same package: mlflowCVE-2023-11779.8MLflow: path traversal allows arbitrary file read/write
Same package: mlflowCVE-2026-26359.8mlflow: security flaw enables exploitation
Same package: mlflow