CVE-2026-0897: 
Python vulnerability analysis and mitigation

CVE-2026-0897 is a Denial of Service vulnerability in Google Keras's HDF5 weight loading component (KerasFileEditor) caused by allocation of resources without limits or throttling (CWE-770). It affects Keras versions 3.0.0 through 3.13.0 on all platforms and was disclosed on January 15, 2026. An unauthenticated remote attacker can craft a malicious .keras archive containing a model.weights.h5 file with an extremely large declared dataset shape, triggering unbounded memory allocation and crashing the Python interpreter. The CVSS v3.1 base score is 7.5 (High) and the CVSS v4.0 base score is 7.1 (High) (Red Hat Advisory, GitHub Advisory).

The root cause is CWE-770 (Allocation of Resources Without Limits or Throttling) in keras/src/saving/file_editor.py. When loading a .keras archive, the _extract_weights_from_store method calls value[()] on each HDF5 dataset, which instructs h5py to allocate RAM proportional to the dataset's declared shape — without first validating that shape against any size limit. An attacker can craft a .keras archive (100–400 KB with gzip compression) containing a model.weights.h5 file whose dataset declares a shape such as (50_000_000, 50_000_000), causing h5py to attempt allocating approximately 8.88 PiB of memory. The fix (merged December 29, 2025, via PR #21880) adds validation checks for negative dimensions, tensor rank exceeding 64, and a 4 GiB maximum memory limit before any dataset is loaded (Keras PR #21880, Keras Commit).

Successful exploitation causes immediate memory exhaustion, crashing the Python interpreter, TensorFlow/JAX/PyTorch backends, and Jupyter kernels — resulting in a complete Denial of Service. Any system or pipeline that loads untrusted .keras model files is at risk, including MLOps backends, model upload endpoints, training services, and automated inference pipelines. There is no confidentiality or integrity impact; the vulnerability is limited to availability (Red Hat Advisory, GitHub Advisory).

No public proof-of-concept exploit has been confirmed as weaponized, and there is no evidence of in-the-wild exploitation at this time. A PoC repository (github.com/HyperPS/CVE-2026-0897) appeared in late May 2026, and exploit references have been observed on Sploitus (PacketStorm IDs 218116 and 219685), indicating increasing public availability of exploit code. The EPSS score is approximately 0.127%, reflecting low but non-negligible exploitation probability. The vulnerability is not listed in the CISA KEV catalog. Detection is available via Nessus plugin 291304 and Qualys detection ID 916702 (Feedly, GitHub Advisory).

1. Craft the malicious archive: Create a valid .keras archive structure. Inside, include a model.weights.h5 file (HDF5 format) with a dataset whose declared shape is extremely large (e.g., (50_000_000, 50_000_000)) but stores only a few bytes of actual data, compressed with gzip to keep the file small (100–400 KB).
2. Deliver the file: Upload the crafted .keras file to a target system — for example, via a model upload endpoint, a shared model repository, or by social engineering a user into loading the file in a Jupyter notebook or ML pipeline.
3. Trigger model loading: The victim system calls keras.models.load_model('malicious.keras') or uses KerasFileEditor to process the file, which invokes _extract_weights_from_store.
4. Trigger unbounded allocation: The vulnerable code executes result[key] = value[()] on the HDF5 dataset. h5py reads the declared shape metadata and attempts to allocate RAM proportional to the declared shape (e.g., ~8.88 PiB), without any size validation.
5. Achieve DoS: The system's memory is exhausted, causing the Python interpreter to crash (OOM kill), the Jupyter kernel to die, or the MLOps service to become unavailable (Keras PR #21880, Feedly).

• File System: Presence of unexpected or externally sourced .keras archive files in model directories or upload staging areas; model.weights.h5 files that are unusually small (under 1 MB) but claim large dataset shapes when inspected with h5py.
• Process/Memory: Sudden spike in memory consumption by a Python process loading a .keras file, followed by an OOM kill or process crash; Jupyter kernel restart events correlated with model loading operations.
• Logs: Python tracebacks referencing keras/src/saving/file_editor.py and _extract_weights_from_store; MemoryError or OOM-related messages in application or system logs; kernel crash logs in Jupyter environments.
• Network: Unexpected inbound uploads of .keras files to model serving or training endpoints from untrusted sources.

The primary remediation is to upgrade Google Keras to version 3.14.0 or later, which includes the fix merged on December 29, 2025 (commit 7360d4f). Patch releases 3.12.1, 3.12.2, and 3.13.2 also contain the backported fix. As interim workarounds: restrict acceptance of .keras model files to trusted sources only; implement pre-processing validation to inspect HDF5 dataset shapes before loading; and apply system-level memory quotas (e.g., ulimit -v) to Python processes handling model files to limit the blast radius of any exploitation attempt (Keras PR #21880, Red Hat Advisory, GitHub Advisory).

The vulnerability was originally reported by researcher HyperPS via Huntr and GHSA, and the fix was contributed directly to the Keras repository via PR #21880, which was reviewed and merged by Keras maintainer hertschuh. Red Hat tracked the issue as a high-severity bug (Bugzilla #2430027) and later issued errata RHSA-2026:4271. A follow-up GitHub issue (#22031) requested backporting the fix to Keras 3.12.x, reflecting community concern about older supported versions. The Gemini Code Assist bot described the fix as addressing a "critical security vulnerability" in its automated review (Keras PR #21880, Red Hat Bugzilla).