A vulnerability in keras-team/keras version 3

This is another entry in the long-running Keras Lambda layer deserialization saga (CWE-502). Version 3.15.0 ships a model-loading path where a crafted .keras archive can smuggle attacker-controlled Python bytecode through Lambda.from_config() because the safe_mode=None default fails open in certain call sites (keras.layers.deserialize, keras.models.clone_model, and any direct from_config invocation outside a SafeModeScope(True) block). When a data scientist or an inference server calls keras.models.load_model('attacker.keras'), arbitrary code executes as the loading process — full RCE at the user/service context.

The vendor's HIGH / 7.8 rating is directionally correct but overstated for a typical enterprise. The CVSS vector (AV:L/AC:L/PR:N/UI:R) already captures the two big shackles: local attack vector and user interaction required. This is not a wormable network bug; it is a supply-chain-flavored code-execution primitive that fires only when someone chooses to load a hostile model file. For a shop that pulls models exclusively from an internal registry with signed provenance, the real severity is MEDIUM. For an ML platform that ingests arbitrary user-submitted .keras files (HuggingFace mirror, Kaggle-style pipeline, MLOps SaaS), the role-multiplier pushes it up to HIGH.

Why this verdict

• Friction — user interaction required: No .keras file gets deserialized without a human or pipeline calling load_model(). Removes drive-by and network-reachable exploitation.
• Friction — local attack vector: Nothing listens on a port. The attacker needs a delivery channel (model hub, phishing, poisoned artifact registry). That is one full compromise step ahead of most attackers.
• Friction — narrow install base at risk: Only orgs on exactly the vulnerable Keras release AND loading untrusted models are exposed. Most production ML shops pin Keras versions per-project and load only in-house artifacts.
• Role multiplier — data scientist workstation: Chain succeeds; blast radius is one laptop's creds and any cloud tokens it holds. Bad but contained. Keeps floor at MEDIUM.
• Role multiplier — public MLOps ingestion platform (HuggingFace-style, model marketplace, SaaS fine-tuning): Chain succeeds trivially because untrusted models are the *product*. Blast radius is tenant-scale — customer data, model IP, pipeline credentials. For these orgs the floor rises to HIGH, but this is <10% of the Keras install base, so it does not push the global verdict to CRITICAL.
• No KEV, no observed campaigns, no network reachability — nothing forces the mitigation window shorter than the standard MEDIUM SLA.

Why not higher?

HIGH would require either KEV listing, evidence of in-the-wild exploitation, or the affected component being canonically a high-value-role service. Keras is a library, not an identity/CA/hypervisor/edge appliance, and the exploitation model demands cooperative user action. Neither the population nor the reachability supports HIGH for the median enterprise.

Why not lower?

LOW / IGNORE would be wrong because working PoCs exist for the class, RCE is confirmed rather than theoretical, and the ML supply chain is a real and rising attack surface. Any org loading community models on this version is genuinely exposed.

1. Force safe_mode=True at every load_model call site — Grep your codebase for keras.models.load_model, keras.layers.deserialize, and clone_model; wrap in with keras.config.SafeModeScope(True): or pass safe_mode=True explicitly. Do this within the noisgate MEDIUM window — no mitigation SLA, but this is a 1-hour lift that should not wait.
2. Pin Keras away from 3.15.0 — In requirements.txt / pyproject.toml / Pipfile, downgrade to the last known-good 3.x release or hold at the patched release once published. Trigger a full CI re-lock and rebuild container images.
3. Enforce model provenance at the artifact registry — Only allow .keras artifacts signed with an internal key (Sigstore / cosign) into your MLflow/W&B/S3 model registry. Block ad-hoc wget of third-party checkpoints from developer environments via egress proxy policy.
4. Deploy YARA scanning on model archives — Use HiddenLayer's public rules (or roll your own detecting marshalled bytecode in config.json inside .keras zips) at your artifact gate and email gateway.
5. Segment ML training/inference IAM — Ensure Jupyter/Airflow/KubeFlow workers hold only short-lived, least-privilege cloud tokens. This caps blast radius when the RCE does fire.

Run on any host with the Python environment you want to audit. Invoke as python check_cve_2026_12484.py from inside the target virtualenv / conda env / container. No elevated privileges required — this is a pure package-introspection check.

#!/usr/bin/env python3
# noisgate verification: CVE-2026-12484 keras Lambda deserialization RCE
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import sys

VULN_VERSIONS = {"3.15.0"}
# Add the fixed version here once vendor publishes it
FIXED_MIN = None  # e.g., "3.15.1"

def parse(v):
    try:
        return tuple(int(x) for x in v.split(".")[:3])
    except Exception:
        return None

try:
    import keras
except ImportError:
    print("UNKNOWN: keras not installed in this environment")
    sys.exit(2)

ver = getattr(keras, "__version__", None)
if not ver:
    print("UNKNOWN: cannot determine keras version")
    sys.exit(2)

print(f"Detected keras version: {ver}")

if ver in VULN_VERSIONS:
    print(f"VULNERABLE: keras {ver} is affected by CVE-2026-12484")
    sys.exit(1)

if FIXED_MIN and parse(ver) and parse(FIXED_MIN):
    if parse(ver) >= parse(FIXED_MIN):
        print(f"PATCHED: keras {ver} >= fixed baseline {FIXED_MIN}")
        sys.exit(0)

# Sanity: probe safe_mode guard behaviour
try:
    from keras.src.saving.serialization_lib import SafeModeScope  # noqa
    print("PATCHED (likely): version not in known vulnerable set; confirm against vendor advisory")
    sys.exit(0)
except Exception:
    print("UNKNOWN: could not introspect SafeModeScope; verify manually")
    sys.exit(2)

Sources

1. Huntr — Hunting Vulnerabilities in Keras Model Deserialization
2. OffSeq Threat Radar — CVE-2026-12481 (sibling class)
3. o3.security — CVE-2026-12481 deserialization writeup
4. HiddenLayer — keras.models.load_model .h5 advisory
5. BlueRock — Neutralizing Deserialization Attacks Against AI/ML Workloads
6. HackTricks — Keras Model Deserialization RCE and Gadget Hunting
7. Snyk — Keras CWE-502 tracker
8. CWE-502 — Deserialization of Untrusted Data