critical

CVE-2026-12481

keras: Keras: Arbitrary code execution via deserialization vulnerability

Published 3 Jul 2026Modified 25 Oct 2026CWE 502

In the Trivy database since at least 24 Oct 2026, 07:11 UTCWhen it arrived before that build is not recorded.

Severity by source

NVD9.8CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

GHSA8.8CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Red Hat8.8CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Trivy's own label is CRITICAL. Rated critical by NVD. Rated lower by GHSA (high), Red Hat (high).

Description

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.

Affected packages and fixed versions

Source	Package	Fixed in
debian 11	keras	no fix listed
minimos	py3-keras	3.14.1-r0
pip::GitHub Security Advisory pip	keras	3.12.3, 3.15.0

References

All 11 references

What Attestkeep does with this

Inside your cluster, without you opening a spreadsheet.

KnowsThe scanner refreshes its vulnerability database every six hours.

FindsEvery admitted image is rescanned every 24 hours by default (scan.rescanInterval). When Trivy rates this vulnerability critical for the image's package source, it appears in the image's findings by name. Findings without a fix are left out unless includeUnfixed is on.

Tells youA critical_finding event goes to the channels subscribed to it: e-mail, Slack, Teams, a webhook, Jira, GitLab or GitHub.

RefusesWith a policy that blocks critical findings, a pod with this image is refused at admission, a rollback to it included. Pods already running are not evicted.

RecordsEach decision is recorded with the policy that ran and its hash, then sealed under a signed checkpoint.

Try Attestkeep

Read the docs