Google Keras
CVE-2026-0897
HIGH
GHSA-xfhx-r7ww-5995
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessCraft .keras archive with oversized HDF5 shape
-
DeliveryDeliver via model hub or upload endpoint
-
ExploitVictim app loads model weights
-
ExecutionLoader pre-allocates unbounded memory
-
ImpactMemory exhaustion crashes Python interpreter
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V2 - Validation and Business Logic Resource allocation limits
MITRE ATT&CK
1 technique across 1 tactic: Impact The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires the victim to load a crafted .keras archive that contains a valid model.weights.h5 HDF5 file whose dataset declares an extremely large shape - i.e., the application must call Keras weight/model loading on an attacker-supplied file (UI:P passive interaction). No authentication is required to craft or deliver the file (PR:N), and no special Keras configuration is needed because the flaw is in the default HDF5 weight-loading path for affected versions 3.0.0-3.13.0. The key limiting factor is the trust boundary: systems that only load first-party, trusted models are not realistically exploitable, and the impact is confined to availability (process crash) with no code execution or data disclosure. |
| Impact | Signals are internally consistent and point to a real-but-bounded availability issue. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H) shows the only impact is availability - no confidentiality or integrity loss - and that exploitation requires the victim to load an attacker-supplied model (UI:P). EPSS is very low (0.03%, 8th percentile) and the CVE is not on CISA KEV, with no POC referenced, so there is no evidence of active or imminent mass exploitation. Practical risk concentrates in environments that ingest untrusted or third-party model files (model hubs, MLOps pipelines, services accepting user-uploaded models), where a single crafted archive can crash a worker. For deployments that only load first-party, trusted models the real-world risk is minimal. Overall this is a moderate-priority, patch-on-normal-cycle issue rather than an emergency, with priority rising sharply for any service that deserializes externally sourced .keras files. |
| Exploit ScenarioDerived | An attacker publishes a malicious .keras model to a model-sharing hub or submits it to a service that accepts user-uploaded models. When a victim or a backend worker loads the model, Keras reads the inflated tensor shape from the embedded model.weights.h5 and attempts a massive memory allocation, exhausting RAM and crashing the Python process. No public POC is referenced, and the network attack vector with low complexity means the only real prerequisite is convincing the target to load the file. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv5 – Jun 30, 2026
Memory-exhaustion denial of service in Google Keras 3.0.0 through 3.13.0 lets a remote attacker crash the Python interpreter by getting a victim to load a malicious .keras model archive. The crafted archive embeds a valid model.weights.h5 HDF5 file whose dataset declares an enormously large shape, so the weight loader attempts to allocate unbounded memory during deserialization. There is no public exploit identified at time of analysis, EPSS risk is low (0.03%), and a vendor fix is available.
Earlier versions of this analysis (4)
Denial of service in Google Keras 3.0.0 through 3.13.0 lets a remote attacker crash the Python interpreter and exhaust host memory when a victim loads a malicious .keras model archive. The HDF5 weight-loading path trusts the dataset shape declared inside model.weights.h5 and pre-allocates memory accordingly, so a tiny crafted file declaring an enormous shape forces an unbounded allocation. EPSS is very low (0.03%, 8th percentile) and there is no public exploit identified at time of analysis, but a vendor patch (Keras PR #21880) and Red Hat errata are available.
Memory-exhaustion denial of service in Google Keras 3.0.0 through 3.13.0 lets a remote attacker crash the Python interpreter by supplying a malicious .keras model archive. The crafted archive embeds an otherwise-valid model.weights.h5 HDF5 file whose dataset declares an enormous tensor shape, causing the weight loader to attempt an unbounded allocation when the victim loads the model. There is no public exploit identified at time of analysis, exploitation requires the victim to load the attacker-supplied file (UI:P), and EPSS is very low (0.03%), so this is an availability-only issue rather than a code-execution threat.
Memory-exhaustion denial of service in Google Keras 3.0.0 through 3.13.0 allows a remote attacker to crash the Python interpreter by supplying a malicious .keras model archive. The crafted archive embeds a valid model.weights.h5 HDF5 file whose dataset declares an extremely large shape, causing the weight-loading routine to attempt an unbounded allocation. No public exploit identified at time of analysis; EPSS risk is low at 0.03%, and there is no evidence of active exploitation.
Keras versions up to 3.13.0 is affected by allocation of resources without limits or throttling (CVSS 7.5).
RemediationAI
Upgrade Keras to a fixed release above 3.13.0 that incorporates the upstream fix from https://github.com/keras-team/keras/pull/21880; Red Hat users should apply the platform-specific updates in RHSA-2026:3782, RHSA-2026:3713, or RHSA-2026:4271 as applicable. The upstream fix is available as a PR, so the released patched version is not independently confirmed here - verify the exact fixed version against the merged PR or your distribution's advisory before deploying. Until patched, the most effective compensating control is to stop loading untrusted .keras / model.weights.h5 files: only deserialize models from trusted, integrity-verified sources, and treat user-uploaded models as hostile. For services that must accept external models, isolate the loading step in a sandboxed subprocess or container with a hard memory cgroup limit (ulimit/RLIMIT_AS or a container memory cap) so an oversized allocation kills only that worker rather than the host - the trade-off is added latency and operational complexity per load. Validating or capping declared dataset shapes before allocation is another mitigation but requires custom pre-parsing of the HDF5 file and may reject legitimately large models.
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in pypi
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Keras is the high-level deep-learning API maintained by Google, distributed on PyPI and bundled into many ML stacks (TensorFlow, JAX, and PyTorch backends). The .keras serialization format is a ZIP archive containing the model config plus a model.weights.h5 file in the HDF5 binary format. When Keras loads weights it reads the dataset metadata from the HDF5 file - including the declared tensor shape - and pre-allocates buffers accordingly. The root cause is CWE-770 (Allocation of Resources Without Limits or Throttling): the loader trusts the attacker-controlled shape field and allocates memory proportional to it without validating it against the actual stored data or any sane upper bound, so an absurd shape forces an allocation that exhausts process memory and crashes the interpreter. The affected component is identified by CPE cpe:2.3:a:keras:keras:*:*:*:*:*:*:*:* across all platforms.
Know when Keras gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Network-delivered malicious model with no auth (PR:N) but requires the victim to load it (UI:R); impact is availability-only memory exhaustion, so C:N/I:N/A:H.
Primary rating from Vendor (google).
CVSS VectorVendor: google
Lifecycle Timeline
7DescriptionCVE.org
Allocation of Resources Without Limits or Throttling in the HDF5 weight loading component in Google Keras 3.0.0 through 3.13.0 on all platforms allows a remote attacker to cause a Denial of Service (DoS) through memory exhaustion and a crash of the Python interpreter via a crafted .keras archive containing a valid model.weights.h5 file whose dataset declares an extremely large shape.
Blast Radius
ecosystem impact- 2 pypi packages depend on keras (2 direct, 0 indirect)
Ecosystem-wide dependent count for version 3.0.0.
Executive ViewAI
Google Keras versions 3.0.0 through 3.13.0 contain a denial-of-service vulnerability that allows remote attackers to crash Python interpreters by distributing malicious model files. Organizations with machine learning development teams or production ML deployments that load Keras models from untrusted sources face potential service disruption and system crashes. Immediate patching is required for any systems handling model files in development or production environments.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
Affected Products (CPE)CVE.org
The Keras Model.load_model method can be exploited to achieve arbitrary code execution, even with safe_mode=True. Rated
Deserialization of untrusted data in Keras 3.11.0 through 3.11.2 allows remote code execution when a victim loads a mali
A arbitrary code injection vulnerability in TensorFlow's Keras framework (<2.13) allows attackers to execute arbitrary c
Directory traversal in Keras through 3.11.3 allows an attacker who supplies a crafted tar archive to keras.utils.get_fil
The Keras Model.load_model method can be exploited to achieve arbitrary code execution, even with safe_mode=True. Rated
Path traversal in Keras archive extraction utilities prior to version 3.14.0 allows remote attackers to write files outs
Arbitrary local file disclosure in Keras 3.0.0 through 3.13.1 allows a remote attacker to read sensitive files from a vi
Keras Model.load_model fails to enforce safe_mode=True for the StringLookup layer's vocabulary path handling, so a malic
A safe mode bypass vulnerability in the `Model.load_model` method in Keras versions 3.0.0 through 3.10.0 allows an attac
An issue in keras 3.7.0 allows attackers to write arbitrary files to the user's machine via downloading a crafted tar fi
Exploit-DB