CVE-2026-1462: 
Python vulnerability analysis and mitigation

CVE-2026-1462 is an untrusted deserialization vulnerability in the TFSMLayer class of the Keras deep learning framework that allows attacker-controlled TensorFlow SavedModels to be loaded during deserialization of .keras model files, even when safe_mode=True is explicitly set. This effectively bypasses the security guarantee that safe_mode is intended to provide, enabling arbitrary code execution during model inference under the victim's privileges. The vulnerability affects keras versions prior to 3.13.2 (specifically confirmed in version 3.13.0) and was disclosed on April 13, 2026. It carries a CVSS v3.0 base score of 8.8 (High), assigned by huntr.dev (GitHub Advisory, Keras Commit).

The root cause is classified as CWE-502 (Deserialization of Untrusted Data). The TFSMLayer.from_config() method lacked any validation or safe-mode enforcement, meaning it would unconditionally load external TensorFlow SavedModels referenced by attacker-controlled file paths embedded in a serialized .keras file — regardless of whether safe_mode=True was passed to the top-level loading function. An attacker crafts a malicious .keras model file containing a TFSMLayer whose configuration points to an attacker-controlled SavedModel; when a victim loads this file (e.g., via keras.saving.load_model()), the SavedModel's executable graph code runs automatically during deserialization. The fix, implemented in commit b6773d3, adds a from_config() override to TFSMLayer that raises a ValueError when safe_mode is not explicitly set to False, mirroring the pattern used for Keras's Lambda layer (GitHub Advisory, Keras Commit).

Successful exploitation grants an attacker arbitrary code execution on the victim's machine under the victim's user privileges, with full confidentiality, integrity, and availability impact. Because TensorFlow SavedModels can embed arbitrary executable graph operations, an attacker can exfiltrate sensitive data, install persistent backdoors, pivot to other systems accessible from the victim's environment, or cause denial of service. Environments particularly at risk include ML pipelines, model-sharing platforms, and research workflows where users routinely load .keras model files from external or community sources (GitHub Advisory, Feedly).

As of the time of disclosure, no public proof-of-concept exploit code has been published and there is no evidence of in-the-wild exploitation (Feedly). The vulnerability is not listed in CISA's Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.06–0.07% (22nd percentile), indicating a low near-term exploitation probability. However, the attack vector is network-accessible, requires no privileges, and only requires user interaction (loading a malicious model file), making it a realistic social-engineering or supply-chain attack scenario in ML communities (GitHub Advisory).

1. Craft a malicious TensorFlow SavedModel: Create a TensorFlow SavedModel containing a malicious tf.function or graph operation that executes attacker-controlled code (e.g., a reverse shell or data exfiltration command) when the model is called.
2. Host the SavedModel: Place the malicious SavedModel at an attacker-controlled path accessible to the victim (e.g., a shared network path, a cloud storage bucket, or embedded within the .keras archive itself).
3. Build a malicious .keras file: Wrap the SavedModel in a TFSMLayer, serialize it into a Keras Sequential or Functional model, and save it as a .keras file using model.save('malicious.keras'). The resulting archive will contain a config referencing the attacker-controlled SavedModel path.
4. Deliver the file to the victim: Distribute the malicious .keras file via model-sharing platforms (e.g., Hugging Face Hub), email, or a compromised supply chain repository, enticing the victim to load it.
5. Trigger code execution: When the victim loads the file with keras.saving.load_model('malicious.keras') — even with the default safe_mode=True on unpatched versions — the TFSMLayer.from_config() method unconditionally loads the external SavedModel, executing the attacker's payload under the victim's privileges during model inference (GitHub Advisory, Keras Commit).

• File System: Presence of unexpected .keras files containing a TFSMLayer configuration with external filepath values pointing to remote or unusual paths; unexpected TensorFlow SavedModel directories (containing saved_model.pb) in temporary or user-writable directories.
• Process: Unusual child processes spawned by the Python interpreter during model loading (e.g., bash, curl, wget, python -c, nc); unexpected network connections initiated by a Python/TensorFlow process.
• Network: Outbound connections from a Python/ML process to unknown external IP addresses or domains immediately following a keras.saving.load_model() call; DNS queries for attacker-controlled domains from ML workstations.
• Logs: Python tracebacks or application logs showing TFSMLayer deserialization activity with external file paths; absence of the expected ValueError ("arbitrary code execution") when loading .keras files on unpatched systems with safe_mode=True.

The primary remediation is to upgrade the keras package to version 3.13.2 or later, which introduces safe-mode enforcement in TFSMLayer.from_config() (GitHub Advisory, Keras Commit). As a workaround for environments that cannot immediately upgrade, avoid loading .keras model files from untrusted or unverified sources, and audit any existing pipelines that use TFSMLayer. Organizations should implement strict model provenance policies, restrict model loading to cryptographically verified artifacts, and educate ML practitioners that safe_mode=True did not protect against this class of attack in affected versions.

The vulnerability was reported through the huntr.dev bug bounty platform and received coverage from The Hacker Wire, which published a technical write-up titled "Keras safe_mode Bypass: RCE via TFSMLayer Deserialization" (The Hacker Wire). The issue was also noted on Mastodon by security community accounts. Community reaction highlighted the particular danger of this vulnerability in ML/AI workflows where sharing and loading pre-trained model files is routine practice, and where users may have a false sense of security from the safe_mode flag.