CVE-2026-12484: Keras unsafe pickle deserialization

Q: Is CVE-2026-12484 actively exploited?

No confirmed active exploitation of CVE-2026-12484 has been reported, but organizations should still patch proactively.

Q: How to fix CVE-2026-12484?

1) Patch: upgrade keras-team/keras past 3.15.0 once a fixed release is available (track the huntr.com advisory linked in this CVE for the patched version). 2) Workaround: never call `TorchModuleWrapper.from_config` (directly or via model loading) on configs from untrusted sources; explicitly wrap any deserialization of external Keras models in `keras.config.SafeModeScope(True)` (or equivalent safe-mode enforcement) so unsafe pickle loading is blocked rather than defaulted-on. 3) Harden input handling: treat any externally-sourced model config/checkpoint as untrusted input — validate provenance, prefer signed/verified artifacts, and run untrusted files through a pickle-scanning tool (e.g. `picklescan`) before loading. 4) Detection: audit code paths and MLOps jobs that call `keras.layers.TorchModuleWrapper.from_config` or otherwise deserialize model configs from user uploads, shared storage, or external APIs, and add monitoring/alerting for unexpected subprocess or network activity originating from model-loading services.

Q: What systems are affected by CVE-2026-12484?

This vulnerability affects the following AI/ML architecture patterns: training pipelines, model serving, model registries/model hubs, MLOps pipelines.

Q: What is the CVSS score for CVE-2026-12484?

CVE-2026-12484 has a CVSS v3.1 base score of 7.8 (HIGH). The EPSS exploitation probability is 0.39%.

CISO Take

Keras 3.15.0's public `TorchModuleWrapper.from_config` method calls `torch.load(..., weights_only=False)` by default, meaning any Keras layer config containing PyTorch pickle data gets deserialized without an explicit unsafe opt-in — if that config comes from an untrusted source, it can execute arbitrary code on the host. There's no CVSS score, EPSS data, CISA KEV listing, public exploit, or scanner template yet, and the affected package shows zero prior CVEs, so this looks like a fresh, low-visibility disclosure rather than an actively weaponized bug — but Keras sits at the center of countless training and inference pipelines, so blast radius is potentially large even without hard exploitation telemetry. Risk concentrates wherever your organization loads Keras model configs or checkpoints from external sources: model hubs, shared research artifacts, or MLOps pipelines accepting user- or partner-supplied models. Patch to a fixed keras-team/keras release as soon as one is published, and in the meantime never call `from_config`/`TorchModuleWrapper` on configs from outside your trust boundary unless explicitly wrapped in `SafeModeScope(True)`. Flag any service that deserializes external Keras artifacts for review, and consider scanning incoming model files with a pickle-safety tool before load.

Sources: NVD huntr.com ATLAS

What is the risk?

No CVSS vector or EPSS score is available, and there is no evidence of a public exploit, scanner template, or CISA KEV listing — so near-term mass exploitation is unlikely and confidence in real-world attack activity is LOW. However, the underlying weakness (CWE-502, insecure deserialization via `torch.load` without `weights_only=True`) is a well-understood, high-impact primitive: successful exploitation grants arbitrary code execution on whatever host processes the malicious config, not just a crash or data leak. The realistic exposure is scenario-dependent — it requires an application to pass attacker-influenced Keras layer configs into `from_config` without enforcing safe mode. Organizations that ingest third-party Keras/PyTorch model artifacts (model marketplaces, shared research checkpoints, plugin/agent systems that load configs dynamically) carry materially higher risk than those that only load internally-authored models.

How does the attack unfold?

Malicious artifact distribution

Attacker crafts a Keras layer config embedding a malicious PyTorch pickle payload and distributes it via a model hub, shared checkpoint, or pipeline input.

AML.T0010.003

Unsafe deserialization triggered

Victim calls TorchModuleWrapper.from_config on the untrusted config, invoking torch.load(weights_only=False) without safe-mode enforcement.

AML.T0011.000

Arbitrary code execution

The pickle payload executes attacker-controlled code on the host running the Keras application during model reconstruction.

AML.T0050

Host/environment compromise

Attacker gains a foothold in the ML training or inference environment, enabling data exfiltration, lateral movement, or tampering with subsequent model runs.

Malicious artifact distribution

Attacker crafts a Keras layer config embedding a malicious PyTorch pickle payload and distributes it via a model hub, shared checkpoint, or pipeline input.

AML.T0010.003

Unsafe deserialization triggered

Victim calls TorchModuleWrapper.from_config on the untrusted config, invoking torch.load(weights_only=False) without safe-mode enforcement.

AML.T0011.000

Arbitrary code execution

The pickle payload executes attacker-controlled code on the host running the Keras application during model reconstruction.

AML.T0050

Host/environment compromise

Attacker gains a foothold in the ML training or inference environment, enabling data exfiltration, lateral movement, or tampering with subsequent model runs.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Keras	pip	< 3.12.3	`3.12.3`
64.3K OpenSSF 7.7 1.5K dependents Pushed 2d ago 62% patched ~48d to patch Full package profile →

Do you use Keras? You're affected.

How severe is it?

CVSS 3.1

7.8 / 10

EPSS

0.4%

chance of exploitation in 30 days

Higher than 33% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Moderate

Exploitation Confidence

medium

○ CISA SSVC: Public PoC

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV Local

AC Low

PR None

UI Required

S Unchanged

C High

I High

A High

What should I do?

1 step

1) Patch: upgrade keras-team/keras past 3.15.0 once a fixed release is available (track the huntr.com advisory linked in this CVE for the patched version). 2) Workaround: never call TorchModuleWrapper.from_config (directly or via model loading) on configs from untrusted sources; explicitly wrap any deserialization of external Keras models in keras.config.SafeModeScope(True) (or equivalent safe-mode enforcement) so unsafe pickle loading is blocked rather than defaulted-on. 3) Harden input handling: treat any externally-sourced model config/checkpoint as untrusted input — validate provenance, prefer signed/verified artifacts, and run untrusted files through a pickle-scanning tool (e.g. picklescan) before loading. 4) Detection: audit code paths and MLOps jobs that call keras.layers.TorchModuleWrapper.from_config or otherwise deserialize model configs from user uploads, shared storage, or external APIs, and add monitoring/alerting for unexpected subprocess or network activity originating from model-loading services.

What does CISA's SSVC say?

Decision Attend

Exploitation poc

Automatable No

Technical Impact total

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Code Execution Supply Chain Framework Model AML.T0010.003 - Model AML.T0011.000 - Unsafe AI Artifacts AML.T0018.002 - Embed Malware

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

Annex A.10 - Third-party and customer relationships

NIST AI RMF

GOVERN 6.1 - Policies for third-party AI risk

OWASP LLM Top 10

LLM05 - Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2026-12484?

Keras 3.15.0's public `TorchModuleWrapper.from_config` method calls `torch.load(..., weights_only=False)` by default, meaning any Keras layer config containing PyTorch pickle data gets deserialized without an explicit unsafe opt-in — if that config comes from an untrusted source, it can execute arbitrary code on the host. There's no CVSS score, EPSS data, CISA KEV listing, public exploit, or scanner template yet, and the affected package shows zero prior CVEs, so this looks like a fresh, low-visibility disclosure rather than an actively weaponized bug — but Keras sits at the center of countless training and inference pipelines, so blast radius is potentially large even without hard exploitation telemetry. Risk concentrates wherever your organization loads Keras model configs or checkpoints from external sources: model hubs, shared research artifacts, or MLOps pipelines accepting user- or partner-supplied models. Patch to a fixed keras-team/keras release as soon as one is published, and in the meantime never call `from_config`/`TorchModuleWrapper` on configs from outside your trust boundary unless explicitly wrapped in `SafeModeScope(True)`. Flag any service that deserializes external Keras artifacts for review, and consider scanning incoming model files with a pickle-safety tool before load.

Is CVE-2026-12484 actively exploited?

No confirmed active exploitation of CVE-2026-12484 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-12484?

1) Patch: upgrade keras-team/keras past 3.15.0 once a fixed release is available (track the huntr.com advisory linked in this CVE for the patched version). 2) Workaround: never call `TorchModuleWrapper.from_config` (directly or via model loading) on configs from untrusted sources; explicitly wrap any deserialization of external Keras models in `keras.config.SafeModeScope(True)` (or equivalent safe-mode enforcement) so unsafe pickle loading is blocked rather than defaulted-on. 3) Harden input handling: treat any externally-sourced model config/checkpoint as untrusted input — validate provenance, prefer signed/verified artifacts, and run untrusted files through a pickle-scanning tool (e.g. `picklescan`) before loading. 4) Detection: audit code paths and MLOps jobs that call `keras.layers.TorchModuleWrapper.from_config` or otherwise deserialize model configs from user uploads, shared storage, or external APIs, and add monitoring/alerting for unexpected subprocess or network activity originating from model-loading services.

What systems are affected by CVE-2026-12484?

This vulnerability affects the following AI/ML architecture patterns: training pipelines, model serving, model registries/model hubs, MLOps pipelines.

What is the CVSS score for CVE-2026-12484?

CVE-2026-12484 has a CVSS v3.1 base score of 7.8 (HIGH). The EPSS exploitation probability is 0.39%.

What is the AI security impact?

Affected AI Architectures

training pipelinesmodel servingmodel registries/model hubsMLOps pipelines

MITRE ATLAS Techniques

AML.T0010.003 Model

AML.T0011.000 Unsafe AI Artifacts

AML.T0018.002 Embed Malware

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: Annex A.10

NIST AI RMF: GOVERN 6.1

OWASP LLM Top 10: LLM05

What are the technical details?

Original Advisory

A vulnerability in keras-team/keras version 3.15.0 allows unsafe deserialization of attacker-controlled PyTorch pickle data through the public `keras.layers.TorchModuleWrapper.from_config` method. This method invokes `torch.load(..., weights_only=False)` without requiring an explicit unsafe opt-in, such as a `safe_mode=False` parameter. When called outside a `SafeModeScope(True)` context, the absence of an ambient safe mode state permits unsafe deserialization by default. This issue can lead to arbitrary code execution if untrusted Keras layer configurations are processed using this method. The vulnerability arises because the method does not enforce safe deserialization practices unless explicitly guarded by Keras safe mode.

Exploitation Scenario

An attacker publishes or contributes a Keras model checkpoint (e.g., to a model hub, a shared research repo, or an internal artifact store) whose layer configuration embeds a crafted PyTorch pickle payload wrapped for `TorchModuleWrapper`. A victim's MLOps pipeline or research team downloads the artifact and calls `from_config` to reconstruct the model for further training, fine-tuning, or inference — since no explicit safe-mode guard is in place, `torch.load(..., weights_only=False)` deserializes the pickle and the attacker's payload executes with the privileges of the ML service or workstation, giving the attacker a foothold to exfiltrate data, pivot to other systems, or tamper with the training environment.

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.