CVE-2026-9335: Keras: HDF5 ExternalLink flaw leaks local files on load

GHSA-m8wh-29wm-52mv MEDIUM
Published August 2, 2026
CISO Take

Keras versions up to 3.14.0 fail to enforce their own HDF5 safety checks, letting a malicious .h5, .weights.h5, or .keras file use HDF5 ExternalLinks to pull arbitrary local file content into memory the moment it's loaded via KerasFileEditor or keras.saving.load_weights. This matters because Keras sits under 1,553 downstream packages and is a routine part of model-sharing workflows — any data scientist opening a 'pretrained checkpoint' from a colleague, forum, or model hub is a viable victim, and the CVSS confidentiality-only score (6.5) undersells the risk in environments where model files carry credentials or config alongside weights. Exploitation requires no special privileges beyond convincing someone to load the file (UI:R), which keeps the EPSS score low (0.65%, top 52th percentile) and it's not in CISA KEV or paired with a public exploit or Nuclei template — CISA rates it TRACK, not urgent action. Patch to keras >= 3.12.3 (fixed in 3.15.0) immediately across ML training and inference environments, and until then treat any .h5/.keras/.weights.h5 file from outside your organization as untrusted input requiring sandboxed inspection before loading.

Sources: NVD GitHub Advisory EPSS ATLAS huntr.com

What is the risk?

Medium severity, confidentiality-only impact (CVSS 6.5, C:H/I:N/A:N). Exploitability is moderate: the attacker needs zero authentication and low complexity, but user interaction is required (a victim must actively load the malicious model/weights file), which caps real-world exploitation velocity. No KEV listing, no public PoC, and no Nuclei template exist, and CISA SSVC rates it TRACK rather than Act/Attend — this is not an actively exploited or trivially wormable bug. The real risk driver is exposure surface: Keras' massive install base (1,553 dependents) and the routine practice of sharing/loading model checkpoints from external sources (Hugging Face, forums, collaborators) creates many plausible delivery paths even without a public exploit.

How does the attack unfold?

Craft malicious file
Attacker builds a .h5/.weights.h5/.keras file embedding HDF5 ExternalLinks pointing to sensitive local paths on the intended victim's system.
AML.T0011.000
Delivery
Victim is lured into loading the file — e.g., as a shared pretrained checkpoint — via keras.saving.load_weights or KerasFileEditor.
AML.T0011
Automatic dereference
Keras bypasses its own safe_get_h5_group/safe_get_h5_dataset safeguards and automatically dereferences the ExternalLink, pulling the external file's content into the model or editor's internal structures.
AML.T0037
Disclosure
Sensitive local file contents end up embedded in the loaded model's attributes/weights or editor state, exposing them to the attacker if the model is later shared, inspected, or exfiltrated.
AML.T0025

What systems are affected?

Package Ecosystem Vulnerable Range Patched
Keras pip < 3.12.3 3.12.3
64.3K OpenSSF 7.7 4.1K dependents Pushed 5d ago 62% patched ~48d to patch Full package profile →

Do you use Keras? You're affected.

How severe is it?

CVSS 3.1
6.5 / 10
EPSS
0.8%
chance of exploitation in 30 days
Higher than 54% of all CVEs
Exploitation Status
No known exploitation
Sophistication
Moderate

What is the attack surface?

AV AC PR UI S C I A
AV Network
AC Low
PR None
UI Required
S Unchanged
C High
I None
A None

What should I do?

1 step
  1. 1) Upgrade to keras >= 3.12.3 (or 3.15.0) immediately across all environments that load .h5/.weights.h5/.keras files — this is the only complete fix, since the vulnerable code path bypasses the library's own link-rejection helpers. 2) Until patched, treat model files from untrusted or unverified sources (model hubs, email, forums, external collaborators) as hostile input: load them only in an isolated/sandboxed environment with no sensitive files reachable, and never load them as the same user with access to credentials or secrets. 3) Detection: audit incoming .h5/.keras files for embedded HDF5 ExternalLink/SoftLink references (h5dump or h5py can enumerate links) before they reach production loading code. 4) Pin and monitor keras version in dependency manifests (requirements.txt, pyproject.toml) and flag any pre-3.12.3 installs in SBOM/dependency scanning.

What does CISA's SSVC say?

Decision Track
Exploitation none
Automatable No
Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Article 15 - Accuracy, robustness and cybersecurity
NIST AI RMF
MANAGE 4.1 - Risk treatment for third-party AI resources
OWASP LLM Top 10
LLM03 - Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2026-9335?

Keras versions up to 3.14.0 fail to enforce their own HDF5 safety checks, letting a malicious .h5, .weights.h5, or .keras file use HDF5 ExternalLinks to pull arbitrary local file content into memory the moment it's loaded via KerasFileEditor or keras.saving.load_weights. This matters because Keras sits under 1,553 downstream packages and is a routine part of model-sharing workflows — any data scientist opening a 'pretrained checkpoint' from a colleague, forum, or model hub is a viable victim, and the CVSS confidentiality-only score (6.5) undersells the risk in environments where model files carry credentials or config alongside weights. Exploitation requires no special privileges beyond convincing someone to load the file (UI:R), which keeps the EPSS score low (0.65%, top 52th percentile) and it's not in CISA KEV or paired with a public exploit or Nuclei template — CISA rates it TRACK, not urgent action. Patch to keras >= 3.12.3 (fixed in 3.15.0) immediately across ML training and inference environments, and until then treat any .h5/.keras/.weights.h5 file from outside your organization as untrusted input requiring sandboxed inspection before loading.

Is CVE-2026-9335 actively exploited?

No confirmed active exploitation of CVE-2026-9335 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-9335?

1) Upgrade to keras >= 3.12.3 (or 3.15.0) immediately across all environments that load .h5/.weights.h5/.keras files — this is the only complete fix, since the vulnerable code path bypasses the library's own link-rejection helpers. 2) Until patched, treat model files from untrusted or unverified sources (model hubs, email, forums, external collaborators) as hostile input: load them only in an isolated/sandboxed environment with no sensitive files reachable, and never load them as the same user with access to credentials or secrets. 3) Detection: audit incoming .h5/.keras files for embedded HDF5 ExternalLink/SoftLink references (h5dump or h5py can enumerate links) before they reach production loading code. 4) Pin and monitor keras version in dependency manifests (requirements.txt, pyproject.toml) and flag any pre-3.12.3 installs in SBOM/dependency scanning.

What systems are affected by CVE-2026-9335?

This vulnerability affects the following AI/ML architecture patterns: training pipelines, model serving, MLOps model registries, model sharing/distribution workflows.

What is the CVSS score for CVE-2026-9335?

CVE-2026-9335 has a CVSS v3.1 base score of 6.5 (MEDIUM). The EPSS exploitation probability is 0.77%.

What is the AI security impact?

Affected AI Architectures

training pipelinesmodel servingMLOps model registriesmodel sharing/distribution workflows

MITRE ATLAS Techniques

AML.T0011.000 Unsafe AI Artifacts
AML.T0025 Exfiltration via Cyber Means
AML.T0037 Data from Local System

Compliance Controls Affected

EU AI Act: Article 15
NIST AI RMF: MANAGE 4.1
OWASP LLM Top 10: LLM03

What are the technical details?

Original Advisory

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.load_weights` functions bypass the `safe_get_h5_group` and `safe_get_h5_dataset` 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.load_weights` 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.

Exploitation Scenario

An attacker publishes a Keras model checkpoint (e.g., a 'fine-tuned' .keras file) on a model-sharing forum, GitHub repo, or via a phishing email targeting an ML engineer, embedding an HDF5 ExternalLink that points to a sensitive local path such as ~/.aws/credentials, ~/.ssh/id_rsa, or an internal config file. When the victim loads the file with keras.saving.load_weights to reuse the 'pretrained' weights, or opens it in KerasFileEditor to inspect/edit it, Keras automatically dereferences the ExternalLink and pulls the external file's contents into the model's internal attributes/dataset structures or the editor's in-memory state — bypassing the safe_get_h5_group/safe_get_h5_dataset checks meant to block exactly this. The disclosed data now lives inside the loaded model object, where it can be exfiltrated if the victim later serializes, shares, or uploads that model, or directly inspected by the attacker if they have any subsequent access to the victim's session or environment.

Weaknesses (CWE)

CWE-22 — Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'): The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.

  • [Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylis
  • [Architecture and Design] For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Source: MITRE CWE corpus.

CVSS Vector

CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N

Timeline

Published
August 2, 2026
Last Modified
August 7, 2026
First Seen
August 2, 2026

Related Vulnerabilities