CVE-2026-12481 is a critical code execution flaw (CVSS 9.8) in Keras 3.14.0. The Lambda layer guard fails to apply safe mode when safe_mode is None, the default for from_config() outside a safe mode scope, so attacker supplied bytecode can be deserialized. The record names no fix, so upgrade as soon as one ships and load only models you trust.
What's affected
From the CVE record:
- Product: keras-team/keras, version 3.14.0 as named in the record. The record does not say whether other versions are affected or which version fixes the issue.
- Component: the
Lambdalayer and the_raise_for_lambda_deserialization()function. - Affected call sites:
keras.layers.deserialize(config),keras.models.clone_model(model)and any directLambda.from_config(config)call that is not inside an enclosingSafeModeScope(True). - Weakness class: CWE-502 (deserialization of untrusted data).
- Severity: CVSS 9.8: network reachable, no privileges, no user interaction, High impact on all three properties.
- Fixed version: not named in the record. The only reference is a huntr bounty page. Check the Keras release notes and GitHub advisories before you decide a version is safe.
How to check if you're exposed
Start with where Keras is installed and which version it is.
pip show keras
python -c "import keras; print(keras.__version__)"
Run these inside each virtual environment, container image and notebook environment, because a machine often holds several. For lockfiles, paste requirements.txt or poetry.lock into the free scan at gold.safeguard.sh/scan.
Then ask the question that decides your risk: does your code build layers from configuration that someone else controls?
grep -rnE "deserialize\(|clone_model\(|from_config\(" your_project/
Look at where the config or model comes from. A model file that you trained yourself and keep in a private store is a different risk from a model downloaded from a public hub or uploaded by a user.
What to do now
- Find every Keras install and note its version, including notebook servers, training images and inference services.
- Do not load or deserialize model files or configs from sources you do not trust. Treat a model file like an executable.
- Check the Keras release notes for a version that addresses this CVE, then upgrade and rebuild images. The record does not name the fixed version, so confirm it first.
- Where you build layers from configuration, call the loading code inside a
SafeModeScope(True), as the record describes. Treat this as hardening, not a substitute for the fix. - Run model loading for untrusted files in a sandbox with no network access and no secrets, and with a low privileged account.
- Keep an inventory of the model files your services load and where each one came from.
Why it matters
Keras has a safe mode for loading models. In safe mode, the Lambda layer, which can carry arbitrary Python code serialized as bytecode, is not allowed to be rebuilt from untrusted data. The guard exists because a model file can contain code, and loading it can run that code.
The record describes a logic error in the guard. The function treats safe_mode as unset when it is None, and None is the default value when from_config() is called outside a safe mode scope. The code conflated "unset, which should mean deny" with "explicitly disabled", and let the load go ahead. This is the same shape as many other bugs: a default that should be restrictive is handled like an opt out. The fix pattern is to treat anything other than an explicit allow as deny.
Per the record, the result can be arbitrary operating system level code execution in the context of the server or user process. For ML teams that matters in a particular way. Model files move between teams, hubs and notebooks, and a service that loads whatever a user uploads has made loading a trust decision for every user.
The CVSS vector says network reachable with no privileges, which fits a service that deserializes configs from requests. A local script that only opens your own models has a much lower real exposure, though not zero. The CVE is not in the CISA Known Exploited Vulnerabilities catalog, and the record does not claim exploitation.
Reachability analysis is helpful here. Many projects have Keras installed because a dependency pulled it in, and never call the affected functions with outside data. Finding that out takes minutes with a dependency inventory and a search of the code, and it tells you whether this is a same day fix or a normal maintenance upgrade.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does safe mode protect me from this?
The flaw is in how the guard treats a safe mode value of None. The record says the guard fails when safe_mode is None, which is the default for from_config() outside a SafeModeScope.
Which Keras version has the fix?
The record does not say. It names 3.14.0 as affected. Check the Keras release notes and advisories.
Is it safe to load a model I downloaded?
Treat a model file like code. Load files only from sources you trust, and use a sandbox for anything else.
Sources
- Gold entry and CVE record: CVE-2026-12481.
- Reference listed in the record, not retrievable for this review: huntr bounty report.
Last reviewed: 19 October 2026.
