CVE-2026-9335

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.

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 Keras model loading mechanism (HDF5 integration) allows a remote attacker to read arbitrary local files via a crafted .keras model file using HDF5 external dataset references. This affects Keras versions 3.0.0 through 3.13.1 on all supported platforms.

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.