Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
19 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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.loadmodel() function. The H5IOStore.getitem method in keras/src/saving/savinglib.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.
Recommended action: Upgrade to 3.15.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.loadweights functions bypass the safegeth5group and safegeth5dataset 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. Specifically, KerasFileEditor extracts attributes and datasets from linked files into its internal structures, while keras.saving.loadweights loads weights from linked files into the user's model. This issue can be exploited by providing a malicious .h5, .weights.h5, or .keras file containing ExternalLinks.
Recommended action: Upgrade to 3.15.0 or 3.12.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability in keras-team/keras version 3.15.0 allows unsafe deserialization of attacker-controlled PyTorch pickle data through the public keras.layers.TorchModuleWrapper.fromconfig method. This method invokes torch.load(..., weightsonly=False) without requiring an explicit unsafe opt-in, such as a safemode=False parameter. When called outside a SafeModeScope(True) context, the absence of an ambient safe mode state permits unsafe deserialization by default. This issue can lead to arbitrary code execution if untrusted Keras layer configurations are processed using this method. The vulnerability arises because the method does not enforce safe deserialization practices unless explicitly guarded by Keras safe mode.
Recommended action: Upgrade to 3.15.0 or 3.12.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability in keras-team/keras version 3.12.0 allows an attacker to craft a malicious tar archive that bypasses the filtersafetarinfos validation in keras/src/utils/fileutils.py. Specifically, symlink entries are not subjected to the same ispathindir validation as regular file entries, allowing symlinks to be created outside the intended extraction directory. This can lead to symlink-based file read, file overwrite, or directory escape attacks. The issue is particularly impactful on Python 3.10 and 3.11, where filtersafetarinfos is the sole defense against tar path traversal. This vulnerability is distinct from CVE-2025-12060 and other previously reported issues.
Recommended action: Upgrade to 3.15.0 or 3.12.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability in keras-team/keras version 3.14.0 allows for arbitrary code execution due to improper handling of deserialization in the Lambda layer. Specifically, the raiseforlambdadeserialization() function fails to enforce the safe-mode guard when safemode is set to None, which is the default value when fromconfig() is called outside of a SafeModeScope context. This logic error conflates None (unset/default-deny) with False (explicitly disabled), bypassing the guard and allowing attacker-controlled marshal bytecode to be deserialized. Affected call sites include keras.layers.deserialize(config), keras.models.clonemodel(model), and any direct invocation of Lambda.fromconfig(config) without an enclosing SafeModeScope(True). This vulnerability can be exploited to achieve arbitrary OS-level code execution in the context of the server or user process.
Recommended action: Upgrade to 3.15.0 or 3.12.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Keras versions up to and including 3.13.2 are vulnerable to an arbitrary HDF5 file read due to an incomplete fix for CVE-2026-1669. The vulnerability resides in the H5IOStore.verifydataset() and fileeditor.py methods, which fail to check the dataset.isvirtual property of HDF5 datasets. This allows an attacker to craft a malicious .keras model archive or .h5 weights file containing a Virtual Dataset (VDS) that references external HDF5 files on the victim's filesystem. When the victim loads the model using keras.models.loadmodel() or keras.saving.loadmodel(), the external file is transparently read, leading to potential information disclosure. Fixed in versions 3.12.3 and 3.15.0.
Recommended action: Upgrade to 3.15.0 or 3.12.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A path traversal vulnerability exists in keras-team/keras version 3.14.0, specifically in the DiskIOStore.make method within the Keras 3 model saving and loading library. This vulnerability arises from the improper handling of user-provided layer names, which are used to construct directory paths without sanitizing for parent directory components (..). While forward slashes (/) are restricted in layer names, directory traversal sequences are not. This allows an attacker to craft a malicious Keras model that, when saved or loaded, can escape the intended temporary working directory and perform unauthorized file system operations, such as creating directories or writing files in arbitrary locations.
Recommended action: Upgrade to 3.15.0 or 3.12.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Keras versions prior to 3.14.0 are vulnerable to a path traversal issue in the archive extraction utilities located in keras/src/utils/fileutils.py. The functions filtersafetarinfos() and filtersafezipinfos() validate archive member paths against the process current working directory (CWD) instead of the actual extraction destination. When the process runs with CWD set to /, which is common in Docker containers, CI/CD runners, and Jupyter environments, the validation boundary becomes the filesystem root, allowing traversal paths to bypass the security check. Additionally, the zip filter contains a bug that causes an AttributeError when a blocked entry is encountered, leading to incomplete extraction. Furthermore, Python 3.11 installations lack the filter="data" safety net, leaving them entirely reliant on the flawed CWD-based filter. Exploitation of this vulnerability can result in arbitrary file writes outside the intended extraction directory, enabling attackers to overwrite…
Recommended action: Upgrade to 3.14.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
PyPI keras >= 3.0.0, <= 3.12.0; >= 3.13.0, < 3.13.2
Fixed in
3.13.23.12.1· Vendor fix available
Issue
Keras’s model loader (KerasFileEditor) unsafely loads user-supplied .keras model files containing HDF5-based weight files without performing any validation on HDF5 dataset metadata. An attacker can craft a .keras archive containing a valid model.weights.h5 file whose dataset declares an extremely large shape (e.g. (50000000, 50000000)), but stores only a few bytes. The .keras file remains small (100–400 KB) because HDF5 with gzip compression stores minimal data. During model loading, Keras executes: python result[key] = value[()] loads entire dataset into memory value[()] instructs h5py to allocate RAM proportional to the dataset’s declared shape – in this case 8.88 PiB of memory. This results in: Immediate memory exhaustion Python / TensorFlow crashes Jupyter kernel kill System instability Full Denial of Service on any workload that processes untrusted .keras models This allows an attacker to crash any environment or pipeline that loads .keras models, including MLOps…
Recommended action: Upgrade to 3.13.2 or 3.12.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 safemode=True. This bypasses the security guarantees of safemode 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 fromconfig() method.
Recommended action: Upgrade to 3.13.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
PyPI keras >= 3.13.0, < 3.13.2; >= 3.0.0, < 3.12.1
Fixed in
3.13.23.12.1· Vendor fix available
Issue
TensorFlow / Keras continues to honor HDF5 “external storage” and ExternalLink features when loading weights. A malicious .weights.h5 (or a .keras archive embedding such weights) can direct loadweights() to read from an arbitrary readable filesystem path. The bytes pulled from that path populate model tensors and become observable through inference or subsequent re-save operations. Keras “safe mode” only guards object deserialization and does not cover weight I/O, so this behaviour persists even with safe mode enabled. The issue is confirmed on the latest publicly released stack (tensorflow 2.20.0, keras 3.11.3, h5py 3.15.1, numpy 2.3.4). Impact - Class: CWE-200 (Exposure of Sensitive Information), CWE-73 (External Control of File Name or Path) - What leaks: Contents of any readable file on the host (e.g., /etc/hosts, /etc/passwd, /etc/hostname). - Visibility: Secrets appear in model outputs (e.g., Dense layer bias) or get embedded into newly saved artifacts. - Prerequisites:…
Recommended action: Upgrade to 3.13.2 or 3.12.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Keras's keras.utils.getfile() function is vulnerable to directory traversal attacks despite implementing filtersafepaths(). The vulnerability exists because extractarchive() uses Python's tarfile.extractall() method without the security-critical filter="data" parameter. A PATHMAX symlink resolution bug occurs before path filtering, allowing malicious tar archives to bypass security checks and write files outside the intended extraction directory. Details Root Cause Analysis Current Keras Implementation The Critical Flaw While Keras attempts to filter unsafe paths using filtersafepaths(), this filtering happens after the tar archive members are parsed and before actual extraction. However, the PATHMAX symlink resolution bug occurs during extraction, not during member enumeration. Exploitation Flow: 1. Archive parsing: filtersafepaths() sees symlink paths that appear safe 2. Extraction begins: extractall() processes the filtered members 3. PATHMAX bug triggers: Symlink…
Recommended action: Upgrade to 3.12.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Keras.Model.load_model method, including when executed with the intended security mitigation safe_mode=True, is vulnerable to arbitrary local file loading and Server-Side Request Forgery (SSRF). This vulnerability stems from the way the StringLookup layer is handled during model loading from a specially crafted .keras archive. The constructor for the StringLookup layer accepts a vocabulary argument that can specify a local file path or a remote file path. * Arbitrary Local File Read: An attacker can create a malicious .keras file that embeds a local path in the StringLookup layer's configuration. When the model is loaded, Keras will attempt to read the content of the specified local file and incorporate it into the model state (e.g., retrievable via get_vocabulary()), allowing an attacker to read arbitrary local files on the hosting system. * Server-Side Request Forgery (SSRF): Keras utilizes tf.io.gfile for file operations. Since tf.io.gfile supports remote filesystem handlers…
Recommended action: Upgrade to 3.12.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Deserialization of untrusted data can occur in versions of the Keras framework running versions 3.11.0 up to but not including 3.11.3, enabling a maliciously uploaded Keras file containing a TorchModuleWrapper class to run arbitrary code on an end user’s system when loaded despite safe mode being enabled. The vulnerability can be triggered through both local and remote files.
Recommended action: Upgrade to 3.11.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Note: This report has already been discussed with the Google OSS VRP team, who recommended that I reach out directly to the Keras team. I’ve chosen to do so privately rather than opening a public issue, due to the potential security implications. I also attempted to use the email address listed in your SECURITY.md, but received no response. --- Summary When a model in the .h5 (or .hdf5) format is loaded using the Keras Model.loadmodel method, the safemode=True setting is silently ignored without any warning or error. This allows an attacker to execute arbitrary code on the victim’s machine with the same privileges as the Keras application. This report is specific to the .h5/.hdf5 file format. The attack works regardless of the other parameters passed to loadmodel and does not require any sophisticated technique—.h5 and .hdf5 files are simply not checked for unsafe code execution. From this point on, I will refer only to the .h5 file format, though everything equally applies to .hdf5.…
Recommended action: Upgrade to 3.11.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Arbitrary Code Execution in Keras Keras versions prior to 3.11.0 allow for arbitrary code execution when loading a crafted .keras model archive, even when safemode=True. The issue arises because the archive’s config.json is parsed before layer deserialization. This can invoke keras.config.enableunsafedeserialization(), effectively disabling safe mode from within the loading process itself. An attacker can place this call first in the archive and then include a Lambda layer whose function is deserialized from a pickle, leading to the execution of attacker-controlled Python code as soon as a victim loads the model file. Exploitation requires a user to open an untrusted model; no additional privileges are needed. The fix in version 3.11.0 enforces safe-mode semantics before reading any user-controlled configuration and prevents the toggling of unsafe deserialization via the config file. Affected versions: < 3.11.0 Patched version: 3.11.0 It is recommended to upgrade to version 3.11.0 or…
Recommended action: Upgrade to 3.11.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
It is possible to bypass the mitigation introduced in response to CVE-2025-1550, when an untrusted Keras v3 model is loaded, even when “safemode” is enabled, by crafting malicious arguments to built-in Keras modules. The vulnerability is exploitable on the default configuration and does not depend on user input (just requires an untrusted model to be loaded). Impact | Type | Vector |Impact| | -------- | ------- | ------- | |Unsafe deserialization |Client-Side (when loading untrusted model)|Arbitrary file overwrite. Can lead to Arbitrary code execution in many cases.| Details Keras’ safemode flag is designed to disallow unsafe lambda deserialization - specifically by rejecting any arbitrary embedded Python code, marked by the “lambda” class name. https://github.com/keras-team/keras/blob/v3.8.0/keras/src/saving/serializationlib.py#L641 - A fix to the vulnerability, allowing deserialization of the object only from internal Keras modules, was introduced in the commit…
Recommended action: Upgrade to 3.11.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The Keras Model.loadmodel function permits arbitrary code execution, even with safemode=True, through a manually constructed, malicious .keras archive. By altering the config.json file within the archive, an attacker can specify arbitrary Python modules and functions, along with their arguments, to be loaded and executed during model loading. Patches This problem is fixed starting with version 3.9. Workarounds Only load models from trusted sources and model archives created with Keras. References - https://www.cve.org/cverecord?id=CVE-2025-1550 - https://github.com/keras-team/keras/pull/20751
Recommended action: Upgrade to 3.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A arbitrary code injection vulnerability in TensorFlow's Keras framework (<2.13) allows attackers to execute arbitrary code with the same permissions as the application using a model that allow arbitrary code irrespective of the application.
Recommended action: Upgrade to 2.13.1rc0 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.