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

CVE-2026-12481 has a CVSS 3.1 base score of 9.8 (Critical). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.4%.

Which versions of Keras are affected by CVE-2026-12481?

Keras 3.14.0 contains a critical remote code execution vulnerability allowing attackers to execute arbitrary OS commands through malicious serialized model layers; publicly available exploit code…. A patch is available.

How to fix or mitigate CVE-2026-12481?

24 hours: Conduct rapid inventory of systems running keras-team/keras 3.14.0 and assess network exposure; immediately restrict external access to model loading endpoints and isolate affected services from sensitive networks. 7 days: Implement input validation on deserialized model data and disable Lambda layer deserialization from untrusted sources; evaluate alternative serialization formats (e.g., SavedModel). 30 days: Monitor Keras release channels for patch availability (watch for 3.14.1 or later) and prepare upgrade plan; validate patched versions in non-production environments before deployment.

Keras CVE-2026-12481

EUVD-2026-41600 CRITICAL

Deserialization of Untrusted Data (CWE-502)

2026-07-03 @huntr_ai

GHSA-5gwj-m78q-7pq3

RCE Deserialization Red Hat Keras Team Keras Keras Team

9.8

CVSS 3.1 · NVD

Severity by source

Vendor (huntr_ai) PRIMARY

HIGH

qualitative

NVD

9.8 CRITICAL

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

vuln.today AI

9.8 CRITICAL

Malicious model is delivered over the network and loaded without auth or interaction (AV:N/PR:N/UI:N), low-complexity deserialization yields full OS code execution (C/I/A:H).

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Red Hat

8.8 HIGH

qualitative

Primary rating from Vendor (huntr_ai).

CVSS VectorNVD

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Updated

Jul 08, 2026 - 15:13 vuln.today

v2 (cvss_changed)

Re-analysis Queued

Jul 08, 2026 - 15:07 vuln.today

cvss_changed

Severity Changed

Jul 08, 2026 - 15:07 NVD

HIGH CRITICAL

CVSS changed

Jul 08, 2026 - 15:07 NVD

8.8 (HIGH) 9.8 (CRITICAL)

Analysis Generated

Jul 03, 2026 - 21:51 vuln.today

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

1 pypi packages depend on keras (1 direct, 0 indirect)

Ecosystem-wide dependent count for version 3.13.0.

DescriptionNVD

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.

AnalysisAI

Arbitrary code execution in keras-team/keras 3.14.0 lets remote attackers run OS-level commands by supplying a malicious serialized Lambda layer that is deserialized without an active SafeModeScope. The root cause is _raise_for_lambda_deserialization() treating a None safe_mode (the default when from_config() runs outside a SafeModeScope) as if it were an explicit False, so the safe-mode guard is skipped and attacker-controlled marshal bytecode executes. SSVC rates technical impact as total with a proof-of-concept available; EPSS is modest at 0.40% (32nd percentile), and the flaw is not in CISA KEV.

Technical ContextAI

Keras is a widely used high-level neural-network API (the keras-team/keras package) whose model/layer serialization format allows a Lambda layer to carry arbitrary Python code. On load, Lambda.from_config() can reconstruct that callable from marshal-encoded bytecode, which is why Keras added a safe_mode guard and a SafeModeScope context manager to block untrusted Lambda deserialization. This is a classic CWE-502 (Deserialization of Untrusted Data) issue: the guard _raise_for_lambda_deserialization() uses tri-state logic where None should mean unset/default-deny but is conflated with False (explicitly disabled). Because safe_mode defaults to None outside a SafeModeScope, entry points such as keras.layers.deserialize(config), keras.models.clone_model(model), and direct Lambda.from_config(config) calls fall through the guard and execute the embedded bytecode.

RemediationAI

No vendor-released patched version is identified in the supplied data, so the fix version cannot be cited (EUVD lists only 'unspecified ≤latest' and no tagged release is provided); monitor the Huntr report (https://huntr.com/bounties/59ceaed1-c8a3-4135-8f94-169ade02823d) and NVD (https://nvd.nist.gov/vuln/detail/CVE-2026-12481) for the patched release and upgrade as soon as it is published. As compensating controls, never call keras.layers.deserialize, keras.models.clone_model, or Lambda.from_config on models from untrusted sources, and explicitly wrap all deserialization in with SafeModeScope(True): so the guard cannot fall through on the default safe_mode=None - the trade-off is that legitimate models that genuinely rely on Lambda-embedded code will fail to load and must be refactored to registered/custom layers. Additionally, restrict and validate the provenance of model files (signed artifacts, trusted registries only), and isolate model-loading processes with least-privilege OS accounts and sandboxing so that a successful deserialization does not yield high-privilege OS execution.