CVE-2026-12481: Keras: safe_mode=None bypass enables Lambda RCE

GHSA-5gwj-m78q-7pq3 CRITICAL CISA: ATTEND
Published July 3, 2026
CISO Take

Keras 3.14.0 contains a logic flaw in its Lambda layer deserialization guard: the safety check treats `safe_mode=None` (the default when `from_config()` is called outside a `SafeModeScope`) as if it were explicitly disabled, allowing attacker-controlled marshal bytecode to execute arbitrary OS commands during model load. This matters because Keras sits at the base of countless model-serving, fine-tuning, and notebook pipelines, and any code path that calls `keras.layers.deserialize()`, `keras.models.clone_model()`, or `Lambda.from_config()` without wrapping it in `SafeModeScope(True)` is silently exposed by default, not by misconfiguration. There is no CISA KEV listing, no public exploit, and no Nuclei template yet, and EPSS sits at 0.4% (top 68th percentile) — so this looks pre-weaponization rather than actively exploited, but the vulnerability class (unsafe pickle/marshal-style deserialization in ML model loading) has a long track record of rapid PoC turnaround once details circulate via the huntr bounty writeup. Upgrade past the affected 3.14.0 release as soon as a patched Keras version is available, and in the interim explicitly enforce `SafeModeScope(True)` (or `safe_mode=True`) around every `from_config`/`deserialize`/`clone_model` call and treat any model file from an untrusted source as executable code, not data.

Sources: NVD EPSS ATLAS

What is the risk?

Moderate-to-high latent severity, currently low observed exploitation. The flaw grants arbitrary OS-level code execution — the worst-case outcome for a deserialization bug — but exploitation requires an attacker to supply a crafted model/config that gets loaded through an unguarded Keras deserialization path, which typically means either a malicious model file (supply chain) or an application that loads user-supplied models/configs. No CVSS score is published yet, EPSS is low (0.4%, 68th percentile), it is not in CISA KEV, and there is no public exploit or Nuclei template. The real risk driver is Keras's ubiquity as a foundational ML library: any organization loading third-party or user-supplied `.keras`/`.h5` models or configs without an explicit safe-mode wrapper is exposed by default, making this a supply-chain-adjacent risk rather than a directly internet-facing one.

How does the attack unfold?

Craft malicious artifact
Attacker builds a Keras model/config containing a Lambda layer with marshal bytecode designed for OS command execution.
AML.T0018.002
Distribute artifact
Attacker publishes or delivers the malicious model file to a victim via a model hub, repository, or direct upload endpoint.
AML.T0011.000
Unsafe deserialization
Victim application calls keras.layers.deserialize(), clone_model(), or Lambda.from_config() outside a SafeModeScope(True), so safe_mode defaults to None and the guard is bypassed.
AML.T0010.001
Arbitrary code execution
The embedded marshal bytecode executes with the privileges of the loading process, giving the attacker OS-level command execution on the host.
AML.T0050

What systems are affected?

Package Ecosystem Vulnerable Range Patched
Keras pip < 3.12.3 3.12.3
64.2K OpenSSF 7.1 1.6K dependents Pushed 3d ago 59% patched ~50d to patch Full package profile →

Do you use Keras? You're affected.

How severe is it?

CVSS 3.1
9.8 / 10
EPSS
0.5%
chance of exploitation in 30 days
Higher than 38% of all CVEs
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 AC PR UI S C I A
AV Network
AC Low
PR None
UI None
S Unchanged
C High
I High
A High

What should I do?

1 step
  1. 1) Upgrade Keras past 3.14.0 once a patched release addressing _raise_for_lambda_deserialization() is available — track the huntr advisory and keras-team release notes. 2) Until patched, explicitly wrap every keras.layers.deserialize(), keras.models.clone_model(), and Lambda.from_config() call in with keras.saving.SafeModeScope(True): rather than relying on the default. 3) Never load Keras models or configs from untrusted or unauthenticated sources (user uploads, public model hubs, third-party partners) without this guard. 4) Detection: audit codebases for from_config(, clone_model(, and layers.deserialize( call sites lacking an enclosing SafeModeScope; add a static-analysis or CI grep rule to catch regressions. 5) Where feasible, run model-loading services in a sandboxed/least-privilege container so that even successful marshal bytecode execution has minimal blast radius.

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?

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001
A.6.2.6 - AI system data and artifact security
NIST AI RMF
MAP-3.4 - Third-party AI resources risk assessment
OWASP LLM Top 10
LLM05 - Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2026-12481?

Keras 3.14.0 contains a logic flaw in its Lambda layer deserialization guard: the safety check treats `safe_mode=None` (the default when `from_config()` is called outside a `SafeModeScope`) as if it were explicitly disabled, allowing attacker-controlled marshal bytecode to execute arbitrary OS commands during model load. This matters because Keras sits at the base of countless model-serving, fine-tuning, and notebook pipelines, and any code path that calls `keras.layers.deserialize()`, `keras.models.clone_model()`, or `Lambda.from_config()` without wrapping it in `SafeModeScope(True)` is silently exposed by default, not by misconfiguration. There is no CISA KEV listing, no public exploit, and no Nuclei template yet, and EPSS sits at 0.4% (top 68th percentile) — so this looks pre-weaponization rather than actively exploited, but the vulnerability class (unsafe pickle/marshal-style deserialization in ML model loading) has a long track record of rapid PoC turnaround once details circulate via the huntr bounty writeup. Upgrade past the affected 3.14.0 release as soon as a patched Keras version is available, and in the interim explicitly enforce `SafeModeScope(True)` (or `safe_mode=True`) around every `from_config`/`deserialize`/`clone_model` call and treat any model file from an untrusted source as executable code, not data.

Is CVE-2026-12481 actively exploited?

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

How to fix CVE-2026-12481?

1) Upgrade Keras past 3.14.0 once a patched release addressing `_raise_for_lambda_deserialization()` is available — track the huntr advisory and keras-team release notes. 2) Until patched, explicitly wrap every `keras.layers.deserialize()`, `keras.models.clone_model()`, and `Lambda.from_config()` call in `with keras.saving.SafeModeScope(True):` rather than relying on the default. 3) Never load Keras models or configs from untrusted or unauthenticated sources (user uploads, public model hubs, third-party partners) without this guard. 4) Detection: audit codebases for `from_config(`, `clone_model(`, and `layers.deserialize(` call sites lacking an enclosing `SafeModeScope`; add a static-analysis or CI grep rule to catch regressions. 5) Where feasible, run model-loading services in a sandboxed/least-privilege container so that even successful marshal bytecode execution has minimal blast radius.

What systems are affected by CVE-2026-12481?

This vulnerability affects the following AI/ML architecture patterns: model serving, training pipelines, ml-ops platforms, notebook/research environments.

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

CVE-2026-12481 has a CVSS v3.1 base score of 9.8 (CRITICAL). The EPSS exploitation probability is 0.47%.

What is the AI security impact?

Affected AI Architectures

model servingtraining pipelinesml-ops platformsnotebook/research environments

MITRE ATLAS Techniques

AML.T0010.001 AI Software
AML.T0011.000 Unsafe AI Artifacts
AML.T0018.002 Embed Malware
AML.T0050 Command and Scripting Interpreter

Compliance Controls Affected

ISO 42001: A.6.2.6
NIST AI RMF: MAP-3.4
OWASP LLM Top 10: LLM05

What are the technical details?

Original Advisory

A vulnerability in keras-team/keras version 3.14.0 allows for arbitrary code execution due to improper handling of deserialization in the `Lambda` layer. Specifically, the `_raise_for_lambda_deserialization()` function fails to enforce the safe-mode guard when `safe_mode` is set to `None`, which is the default value when `from_config()` is called outside of a `SafeModeScope` context. This logic error conflates `None` (unset/default-deny) with `False` (explicitly disabled), bypassing the guard and allowing attacker-controlled `marshal` bytecode to be deserialized. Affected call sites include `keras.layers.deserialize(config)`, `keras.models.clone_model(model)`, and any direct invocation of `Lambda.from_config(config)` without an enclosing `SafeModeScope(True)`. This vulnerability can be exploited to achieve arbitrary OS-level code execution in the context of the server or user process.

Exploitation Scenario

An attacker crafts a malicious `.keras` model file (or a bare model config) containing a `Lambda` layer whose serialized function is Python `marshal` bytecode that executes an OS command on load — e.g., a reverse shell or credential-harvesting payload. The attacker distributes this file via a public model-sharing platform, a pull request to an ML repo, or directly to a victim organization's model upload/inference endpoint, disguised as a legitimate fine-tuned model. When the victim's application calls `keras.models.clone_model()` or `keras.layers.deserialize()` on the file without wrapping it in `SafeModeScope(True)` — the default, unguarded behavior — the marshal bytecode executes with the privileges of the loading process, giving the attacker code execution on the model-serving host or the data scientist's workstation.

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:N/UI:N/S:U/C:H/I:H/A:H

Timeline

Published
July 3, 2026
Last Modified
August 7, 2026
First Seen
July 3, 2026

Related Vulnerabilities