The MLflow pickle deserialization vulnerability disclosed through CERT/CC VU#369093 is best understood as a model-loading safety-control problem, not as evidence that every MLflow server is remotely exploitable. CERT/CC says affected MLflow flavor paths could bypass the MLFLOW_ALLOW_PICKLE_DESERIALIZATION protection and allow code execution when a victim loads a malicious model artifact.
The most important current detail is that the remediation state is not identical for the two affected flavor paths discussed in the disclosure. The statsmodels path has a clear patched version, while the DSPy wording in CERT/CC’s September 16 note conflicts with released MLflow source code that already contains the relevant guard.
MLflow pickle deserialization vulnerability: what changed
MLflow uses multiple model flavors and serialization paths. The safety setting MLFLOW_ALLOW_PICKLE_DESERIALIZATION is intended to prevent unsafe pickle-based loading when disabled. CERT/CC documented cases where that protection could be bypassed in MLflow’s DSPy and statsmodels model-loading paths.
The practical risk is tied to malicious model content. CERT/CC describes an attack scenario in which an attacker can write or place a crafted model in a location from which the victim later loads it. If the affected loading path deserializes attacker-controlled pickle content, code can execute in the process that loads the model. This is therefore a model-artifact trust problem as well as a software-version problem.
Statsmodels: fixed in MLflow 3.15.0
The statsmodels issue has the clearest version boundary. GitHub’s reviewed security advisory for the flaw lists MLflow versions from 2.1.0 up to, but not including, 3.15.0 as affected and identifies 3.15.0 as the patched release.
For operators still using an older MLflow release with the statsmodels flavor, the safest version decision is straightforward: move to a current supported release rather than relying on the environment variable alone. The control is still useful, but affected older implementations did not enforce it consistently across every relevant loading path.
DSPy: CERT/CC and released MLflow code do not fully align
CERT/CC’s September 16 remediation text says users should avoid the DSPy flavor until further remediation is available. TPS found an important conflict with upstream MLflow code: the tagged MLflow 3.13.0 DSPy loader already contains logic that passes the pickle-permission state into DSPy loading and blocks direct pickle loading when deserialization is not allowed, subject to the documented managed-environment exceptions.
This means TPS cannot responsibly state that DSPy remains unpatched in current MLflow releases. The accurate position is that CERT/CC’s published remediation wording and MLflow’s released code state do not fully match. Until CERT/CC or MLflow publishes a clarification that reconciles the affected-version history, readers should treat the DSPy version boundary as a documented-source conflict rather than convert either side into a stronger claim.
What MLflow administrators should check
- Identify the exact MLflow version deployed in production, development and model-serving environments.
- Determine whether workloads use the statsmodels or DSPy flavors and whether model artifacts can come from shared, externally writable or otherwise untrusted locations.
- Upgrade old MLflow installations to a current supported release rather than treating
MLFLOW_ALLOW_PICKLE_DESERIALIZATIONas a complete substitute for patching. - Review who can upload, replace or modify model artifacts in registries, buckets and artifact stores.
- Prefer non-pickle or pickle-free model formats where MLflow supports them, especially for workflows that exchange models across trust boundaries.
What the disclosure does not establish
The reviewed sources do not establish active exploitation in the wild. They also do not support describing this as an unauthenticated network compromise of every MLflow deployment. The attacker scenario depends on a victim loading a malicious or attacker-controlled model artifact through an affected path.
The reviewed GitHub advisory for the statsmodels issue also does not currently identify a CVE. TPS therefore uses the CERT/CC vulnerability-note identifier and the reviewed GitHub advisory identifier rather than inventing or assuming a CVE number.
Why artifact provenance still matters after upgrading
Upgrading fixes known implementation defects, but it does not make arbitrary serialized Python objects intrinsically safe. Pickle can execute code as part of deserialization, so model provenance remains a security boundary. A current MLflow version, restricted artifact-write access and safer serialization formats should be treated as complementary controls.
What to watch next
The next material change would be a CERT/CC revision that clarifies the DSPy remediation state, an upstream MLflow statement defining the exact historical DSPy affected range, a CVE assignment, or credible evidence of exploitation. Any of those developments should update this same canonical article rather than create a duplicate page for the same reader question.
Verification note: TPS compared the CERT/CC vulnerability note, the reviewed GitHub statsmodels advisory and released MLflow DSPy source code to separate confirmed version boundaries from the unresolved DSPy remediation wording.