MLflow statsmodels flavor ignores the pickle safety switch: loading a crafted model can run arbitrary code

Who is affected

At its core this flaw bypasses a setting users turn on themselves. According to MLflow’s source code, MLFLOW_ALLOW_PICKLE_DESERIALIZATION defaults to True, meaning pickle loading is allowed by default; the CVE record, CERT/CC and MLflow’s GHSA all describe the statsmodels flavor loading pickle anyway after users set it to False.

The range is worded slightly differently: the CVE description says “2.1.0 to 3.14.0”; the CVE record’s structured fields say from 2.1 up to, but not including, 3.15.0; MLflow’s GHSA says 2.1.0 and later are affected, with 3.15.0 patched. The CERT/CC note says the flaw was confirmed against MLflow 3.12.0.

An attack generally needs all of these: you have set MLFLOW_ALLOW_PICKLE_DESERIALIZATION=False; the attacker can write to a place you get models from (such as an artifact store, the storage that holds model files); the model’s MLmodel config file names the statsmodels flavor as its loader; and your code loads it. The CERT/CC note describes the attack path through mlflow.pyfunc.load_model(); according to the MLflow 3.14.0 source code (mlflow/statsmodels/init.py), both _load_pyfunc(), which pyfunc loading calls, and a direct call to mlflow.statsmodels.load_model() reach the same unchecked _load_model(), so both ways of loading are affected. According to the GHSA text, default MLflow deployments without the basic-auth app have login switched off, so uploads need no credentials.

How it works

MLflow uses “flavors” to save and load models built with different libraries. According to MLflow’s documentation, the statsmodels flavor uses pickle internally to save models. Pickle is Python’s format for saving objects, and loading an untrusted pickle file can run code hidden inside it. This class of problem is called unsafe deserialization (CWE-502).

For this reason MLflow offers an environment variable (a setting a program reads at startup), MLFLOW_ALLOW_PICKLE_DESERIALIZATION. It defaults to True, which allows pickle loading; setting it to False forbids it. The problem is that the statsmodels flavor’s _load_model() never checked this setting at all. Operators believed pickle risk was blocked, but this flavor silently loaded pickle anyway. The result: a remote attacker who supplies a crafted model may get arbitrary code to run, with the privileges of the loading process.

The flawed approach (conceptual illustration, not the original source code):

def _load_model(path):
    # Never checks the safety switch; reads the pickle directly
    return read_pickle(path)

The fixed approach:

def _load_model(path):
    if not pickle_deserialization_allowed():
        raise SecurityError("pickle loading is disabled")
    return read_pickle(path)

Timeline

Further reading

• The CVE mapping is disputed. The original CERT/CC note VU#369093 (not only a republished copy) describes the dspy flaw first and the statsmodels flaw second, then says they are CVE-2026-96804 and CVE-2026-96775 “respectively”, which read literally makes this CVE the dspy flaw. The official CVE record maps CVE-2026-96804 to statsmodels, and Strix lists CVE-2026-96775 as the dspy flaw. CERT/CC is also the CNA that published this CVE, so its note and its own CVE record disagree. This page follows the CVE record in mapping CVE-2026-96804 to statsmodels.
• The link to MLflow’s advisory. CERT/CC note VU#369093 lists MLflow’s security advisory GHSA-gqvg-gmmx-x4hm as a reference, and that advisory describes exactly this statsmodels pickle-control bypass. The CVE’s own GitHub entry is a separate, unreviewed advisory, GHSA-2qmw-5xhm-qq5w. This page uses the earlier GHSA-gqvg-gmmx-x4hm publication date, 2026-07-27, as the first disclosure date; the CVE was published on 2026-09-23.
• Scoring differences. In the CVE record, CISA rates it 8.8 with a vector assuming low privileges and no user action; GHSA (on OSV and GitLab) also gives 8.8 but assumes no privileges and user action. NVD’s status is “Deferred”, so NVD has done no analysis of its own.
• Exploitation. Not in CISA KEV; CISA’s assessment says no known exploitation, not automatable, total technical impact. On a public proof-of-concept, TheHackerWire says none is confirmed; another third-party site claims one exists, but its page contains runnable attack code, so this page does not cite it. No source offers evidence on exploitation before a fix existed.
• Coordination. The CERT/CC note says MLflow could not be reached to coordinate these vulnerabilities.
• Related flaws. CERT/CC says a similar bypass in the dspy flavor had no fix yet. A later MLflow pull request, #25566 (merged 2026-09-03), used the statsmodels guard as the pattern for adding the same protection to the mlflow.shap flavor; that PR changes only the shap flavor.