Keras CVE-2026-12570: a model file can exhaust server memory

CVE-2026-12570, a denial-of-service vulnerability in Keras, was published on 10 August 2026. A crafted model file based on HDF5 can remain small on disk while declaring an array measured in petabytes. When keras.models.load_model() tries to materialise it, the process requests an enormous amount of memory and may be killed by the operating system, commonly with exit code 137.

The CNA scores the issue 5.5 under CVSS 3.0 because an attacker must deliver a local file and someone or something must load it. “Local” does not mean irrelevant in a modern model pipeline. An MLOps job may automatically fetch models from a registry, process user uploads or validate artifacts delivered by another team. A tiny file can then repeatedly crash a shared worker, delay releases and cause expensive restart loops.

How an HDF5 shape bomb works

HDF5 stores metadata describing a dataset’s type and shape as well as its physical data. The format supports compression, sparse values and fill-value mechanisms. A file below one megabyte can therefore claim to represent an array with a huge number of elements without immediately writing that whole array to disk.

The failure occurs during materialisation. If an application trusts the declared shape and allocates element_count × type_size, the cost is no longer related to the uploaded byte count. The patch test used a dataset with shape (2**50,) and a float64 type. Its logical size is close to 8 pebibytes even though the file can be smaller than 1 MiB. No ordinary server can satisfy that request.

CVE-2026-12570 affects Keras through version 3.15.0. The condition was in H5IOStore.__getitem__, which read a dataset without a limit tying its declared size to its stored data. This detail matters: an earlier CVE-2026-0897 fix covered KerasFileEditor, so it did not automatically protect every load_model() path.

What the patch changes

The fixing commit adds a two-part control. Keras calculates the logical allocation by multiplying the dataset dimensions by the element size, then compares it with the storage consumed in HDF5. It rejects a dataset when the logical buffer is above 4 GiB and more than one thousand times larger than the stored representation.

Using both conditions reduces false positives. A model larger than 4 GiB is not automatically malicious when it physically stores a similar quantity of data. High compression can also be legitimate for a small object. The suspicious combination is an absolutely large allocation and an extreme expansion ratio. This resembles ZIP-bomb protection, but operates on tensor semantics.

The CNA identifies the affected range as versions through 3.15.0, but teams should not guess the first safe package merely from the commit. Use a release the project explicitly publishes outside the affected range, or verify that the artifact you operate contains the patch. A private backport needs compatibility tests, a reproducible build and documented provenance.

Who should prioritise this issue

Highest priority belongs to services that load models supplied by an untrusted party: public converters, marketplaces, evaluation systems, training platforms, multi-tenant registries and CI jobs analysing pull requests. Organisations that pull models from public repositories without pinning a version and checking provenance also have meaningful exposure.

An application that loads only a model produced by a controlled internal pipeline has lower, but not zero, priority. Ask who can replace the artifact, change its URI, write to the storage bucket or compromise the publishing token. Model security is a property of the entire provenance chain rather than just the source-code repository.

Impact also depends on isolation. On a dedicated worker with a memory limit, one job may fail. On a shared notebook or unlimited orchestrator, memory pressure can disrupt neighbouring processes. A Kubernetes container limit contains the direct blast radius, but a CrashLoop can still consume resources, create costs and block a queue.

What to do now

1. Inventory every Keras dependency, including notebook images, validation jobs, converters and tools that run only occasionally.
2. Inspect the effective version inside each image rather than relying on a dependency declaration. A cached layer may contain an older package.
3. Upgrade to an officially released package outside <=3.15.0, or to a controlled build that contains the referenced commit.
4. Until then, do not load unverified .keras or HDF5 files in a process that can reach production secrets.
5. Set memory, execution-time and restart limits; inspect artifacts in an isolated worker without access to internal networks.
6. Require a digest, signature or approved provenance. Record the author, source and exact version of every model artifact.
7. Monitor OOMKill events, exit code 137, sudden RSS growth and repeat failures after a particular file is downloaded.

An upload-size cap is not enough. The vulnerability exists precisely because the bytes transferred and the semantic expansion cost differ. A 100 MiB filter will allow a sub-1 MiB file that declares a gigantic tensor. The validator must understand format metadata and perform safe arithmetic before allocating memory.

Designing a safer model-ingestion path

A robust pipeline separates at least three stages. The first accepts a file into quarantine and calculates its digest. A second process, deprived of secrets and constrained by strict cgroup limits, analyses structure, shapes, types, operators and dependencies. Only a third stage admits an approved digest to training or inference. The analysis result must bind to the same digest to prevent a swap between inspection and use.

Policy can define a maximum total tensor element count, maximum individual dimension, allowed data types and a reasonable logical-to-physical size ratio. Limits should reflect the application. A language model and a small image classifier have different profiles, but neither needs unconditional permission to allocate petabytes.

Traditional antivirus alone is insufficient because a syntactically valid HDF5 file may carry no known malware signature. This is an attack on data interpretation and availability. Format-aware controls, process isolation and reliability mechanisms are required. Application and operational defences complement one another: a patched library rejects this bomb, while a memory limit protects against a future variation.

Facts, conclusions and the practical lesson

The record and patch establish the unbounded allocation caused by the mismatch between a dataset’s shape and physical file, the affected range through Keras 3.15.0 and the thresholds chosen for the fix. Those sources do not report a mass exploitation campaign. Breachroad’s conclusion is that every automated model import should be treated as parsing an active, potentially hostile artifact rather than reading a passive data file.

This issue is a useful exercise for AI, DevOps and security teams because it joins defensive programming with resilience engineering. Our cybersecurity training for organisations helps teams develop a shared process for dependency risk. Organisations building MLOps can also formalise model provenance, isolation and resource limits through a secure AI implementation review.