CVE-2026-0897: Google Keras HDF5 DoS Vulnerability

CVE-2026-0897 Overview

CVE-2026-0897 is a Denial of Service (DoS) vulnerability discovered in the HDF5 weight loading component of Google Keras, a widely-used open-source deep learning framework. The vulnerability stems from improper resource allocation controls (CWE-770: Allocation of Resources Without Limits or Throttling) that allow an attacker to trigger memory exhaustion and crash the Python interpreter by providing a maliciously crafted .keras archive.

The attack leverages a specially crafted archive containing a valid model.weights.h5 file with a dataset that declares an extremely large shape. When the Keras framework attempts to load this file, it allocates memory based on the declared shape without proper validation or limits, leading to resource exhaustion.

Critical Impact

Successful exploitation can cause complete denial of service through memory exhaustion, crashing the Python interpreter and disrupting machine learning pipelines and production systems that rely on Keras model loading functionality.

Affected Products

• Google Keras versions 3.0.0 through 3.13.0
• All platforms (Windows, Linux, macOS)
• Applications using the HDF5 weight loading functionality

Discovery Timeline

• 2026-01-15 - CVE CVE-2026-0897 published to NVD
• 2026-01-16 - Last updated in NVD database

Technical Details for CVE-2026-0897

Vulnerability Analysis

This vulnerability targets the HDF5 weight loading mechanism in Keras, which is responsible for deserializing model weights stored in the .keras archive format. The HDF5 format allows datasets to declare their shape (dimensions), which Keras uses to allocate memory for loading the weight tensors.

The root issue lies in the absence of validation or throttling when processing the declared shape metadata. An attacker can craft a model.weights.h5 file where the dataset shape declares dimensions that, when multiplied together, result in a memory allocation request far exceeding available system resources.

When a victim application attempts to load a model from such a malicious archive, Keras will attempt to allocate the declared memory size, causing rapid memory exhaustion. This leads to an unrecoverable crash of the Python interpreter, effectively denying service to any application or pipeline that depends on this functionality.

Root Cause

The vulnerability is classified under CWE-770 (Allocation of Resources Without Limits or Throttling). The HDF5 weight loading component fails to implement adequate bounds checking or resource limits when processing dataset shape declarations. The code trusts the shape metadata embedded in the HDF5 file without validating whether the declared dimensions are reasonable or within acceptable memory bounds before attempting allocation.

Attack Vector

The attack is network-based, requiring user interaction to load a malicious .keras archive. Attack scenarios include:

1. Malicious Model Distribution: An attacker uploads a crafted model to a public model repository or shares it through collaboration platforms
2. Supply Chain Attack: Compromised model files distributed through legitimate-looking channels
3. Phishing: Targeted delivery of malicious model archives to machine learning engineers or data scientists

The attacker crafts a .keras archive containing a model.weights.h5 file with an HDF5 dataset declaring an extremely large shape. For example, a shape declaration like (1000000, 1000000, 1000000) would request allocation of several petabytes of memory, far exceeding typical system resources.

When the victim loads the malicious archive using Keras model loading functions, the framework attempts to allocate memory based on the declared shape, leading to immediate memory exhaustion and interpreter crash.

Detection Methods for CVE-2026-0897

Indicators of Compromise

• Sudden memory spikes when loading .keras model files
• Python interpreter crashes during model loading operations
• System out-of-memory errors correlated with HDF5 file processing
• Unusual HDF5 files with extremely large declared dataset shapes

Detection Strategies

• Monitor system memory usage during model loading operations for abnormal allocation patterns
• Implement file integrity checks on .keras archives before loading, especially from untrusted sources
• Deploy endpoint detection and response (EDR) solutions like SentinelOne Singularity to detect resource exhaustion patterns
• Scan incoming model files for anomalous HDF5 shape declarations using static analysis tools

Monitoring Recommendations

• Enable memory usage alerts for processes performing Keras model operations
• Log all model loading events with source file hashes and origin information
• Monitor for repeated crash events in ML pipeline services
• Implement canary deployments that test model files in isolated environments before production use

How to Mitigate CVE-2026-0897

Immediate Actions Required

• Upgrade Google Keras to a patched version beyond 3.13.0 when available
• Validate and verify the source of all .keras model files before loading
• Implement model loading in sandboxed environments with memory limits
• Review and restrict access to model loading functionality in production systems

Patch Information

The Keras development team has addressed this vulnerability in a GitHub Pull Request. Organizations should monitor the official Keras repository for the release of a patched version and upgrade immediately when available. The fix implements proper bounds checking and resource limits for dataset shape declarations during HDF5 weight loading.

Workarounds

• Load untrusted model files in isolated containers with strict memory limits using cgroups or container resource constraints
• Implement pre-validation scripts that inspect HDF5 shape declarations before loading models
• Use ulimit on Linux/Unix systems to set hard memory limits for processes that load model files
• Consider implementing a model validation pipeline that tests files in sandboxed environments before allowing production use

# Configuration example
# Set memory limits for processes loading model files
# Linux: Create a cgroup with memory constraints
sudo cgcreate -g memory:/keras_sandbox
echo "4G" | sudo tee /sys/fs/cgroup/memory/keras_sandbox/memory.limit_in_bytes

# Run model loading in constrained environment
sudo cgexec -g memory:keras_sandbox python load_model.py

# Alternative: Use ulimit (less robust)
ulimit -v 4194304  # Limit virtual memory to 4GB
python load_model.py