CVE-2026-1669

A vulnerability in Keras version 3.14.0 allows arbitrary code execution due to improper deserialization handling in the `Lambda` layer. The `_raise_for_lambda_deserialization()` function fails to enforce safe-mode when `safe_mode` is `None` (default), bypassing the guard and allowing attacker-controlled `marshal` bytecode to be deserialized.

A vulnerability in keras-team/keras versions <= 3.15.0 allows for a denial of service (DoS) attack when loading malicious .keras model files via the keras.models.load_model() function. The H5IOStore.__getitem__ method in keras/src/saving/saving_lib.py does not validate the shape or size of datasets, leading to unbounded memory allocation. A specially crafted .keras file can exploit this flaw to trigger an out-of-memory (OOM) condition, causing the process to be terminated (exit code 137). This issue bypasses the fix for CVE-2026-0897, which only addressed a similar vulnerability in KerasFileEditor. The attack vector includes poisoned models from public repositories or malicious model registries, posing a risk to machine learning pipelines that process untrusted models.

A vulnerability in keras-team/keras versions <= 3.14.0 allows arbitrary local HDF5 file content disclosure due to improper handling of HDF5 ExternalLinks. The `KerasFileEditor` and `keras.saving.load_weights` functions bypass the `safe_get_h5_group` and `safe_get_h5_dataset` helpers, which are designed to reject ExternalLinks and SoftLinks. This results in automatic dereferencing of links to external HDF5 files, enabling attackers to disclose sensitive data from the victim's local filesystem.

Keras version 3.15.0 has an unsafe deserialization vulnerability of attacker-controlled PyTorch pickle data through the public `keras.layers.TorchModuleWrapper.from_config` method. This method calls `torch.load(..., weights_only=False)` without requiring an explicit unsafe opt-in. Outside a `SafeModeScope(True)` context, unsafe deserialization is allowed by default, potentially leading to arbitrary code execution.

A vulnerability in Keras version 3.12.0 allows an attacker to craft a malicious tar archive that bypasses the `filter_safe_tarinfos` validation in `keras/src/utils/file_utils.py`. Symlink entries are not validated for directory escape, enabling symlink-based file read, overwrite, or directory escape attacks.

A vulnerability in Keras versions up to and including 3.13.2 allows arbitrary HDF5 file read due to an incomplete fix for CVE-2026-1669. The issue stems from missing checks of the `dataset.is_virtual` property in `H5IOStore._verify_dataset()` and `file_editor.py` methods. An attacker can craft a malicious `.keras` model or `.h5` weights file with a Virtual Dataset (VDS) referencing external HDF5 files.

Keras versions prior to 3.14.0 are vulnerable to a path traversal issue during archive extraction. Validation functions compare archive member paths against the current working directory (CWD) instead of the actual extraction destination, which in environments like Docker, CI/CD, or Jupyter (where CWD is '/') allows bypassing security checks and writing files outside the intended directory.

A vulnerability in the `TFSMLayer` class of the `keras` package, version 3.13.0, allows attacker-controlled TensorFlow SavedModels to be loaded during deserialization of `.keras` models, even when `safe_mode=True`. This bypasses the security guarantees of `safe_mode` and enables arbitrary attacker-controlled code execution during model inference under the victim's privileges. The issue arises due to the unconditional loading of external SavedModels, serialization of attacker-controlled file paths, and the lack of validation in the `from_config()` method.

A vulnerability in the HDF5 weight loading component of Google Keras 3.0.0 through 3.13.0 allows a remote attacker to cause a Denial of Service (DoS) via memory exhaustion and a crash of the Python interpreter. The attack involves a crafted .keras archive containing a model.weights.h5 file with an extremely large dataset shape declaration.