CVE-2026-12480: Keras incomplete fix reopens HDF5

Q: Is CVE-2026-12480 actively exploited?

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

Q: How to fix CVE-2026-12480?

Upgrade to Keras 3.14.1, or 3.12.2 if pinned to the legacy 3.12.x branch. Until patched, do not load .keras or .h5 files from untrusted or unverified sources (public hubs, email attachments, unreviewed PRs); verify checksums/signatures on model artifacts where possible. Load any externally-sourced model in a sandboxed, least-privilege container with restricted filesystem access (no mounted secrets, read-only home directory) so a successful VDS reference has nothing sensitive to reach. Add file-access monitoring/EDR alerting for unexpected reads of credential files or config directories during model-loading processes. Where feasible, prefer safetensors or other formats without embedded external-file-reference capabilities for artifacts of unknown provenance.

Q: What systems are affected by CVE-2026-12480?

This vulnerability affects the following AI/ML architecture patterns: model loading pipelines, model registries/hubs, training pipelines, MLOps CI/CD workflows.

Q: What is the CVSS score for CVE-2026-12480?

CVE-2026-12480 has a CVSS v3.1 base score of 5.5 (MEDIUM). The EPSS exploitation probability is 0.13%.

CISO Take

Keras's earlier fix for a file-disclosure bug (CVE-2026-1669) turned out to be incomplete: versions through 3.13.2 still fail to check whether an HDF5 dataset is a Virtual Dataset (VDS), so a crafted .keras or .h5 file can embed a reference to any other file on the victim's filesystem. When a user simply calls keras.models.load_model() or keras.saving.load_model() on that file, Keras transparently dereferences the VDS and reads the external file's contents — no warning, no sandbox. There's no CVSS score, EPSS data, or CISA KEV listing yet, and no public exploit or scanner template has surfaced, so this isn't an active-exploitation emergency, but the attack surface is wide: Keras models are routinely pulled from public hubs, shared between teams, and loaded in CI/CD and notebooks with minimal scrutiny of the file's origin. Patch to Keras 3.14.1 (or 3.12.2 on the legacy branch) as soon as it fits your release cycle, and in the meantime treat any .keras/.h5 file from outside your organization as untrusted — load it only in an isolated, least-privilege environment.

Sources: NVD ATLAS huntr.com github.com

What is the risk?

Low-to-moderate near-term risk given the absence of a CVSS score, EPSS data, KEV listing, or public PoC — this is not being actively exploited today. However, the bug class is high-value for supply-chain abuse: it requires no special privileges beyond convincing a victim to load a model file, and HDF5 Virtual Dataset crafting is a well-documented technique (this is the second time it has surfaced against the same Keras code path). The fact that the original fix (CVE-2026-1669) missed this exact case suggests the file-loading logic may still have gaps, so risk should be treated as 'moderate and recurring' rather than 'one-off patched'.

How does the attack unfold?

Staging

Adversary crafts a malicious .keras or .h5 file embedding an HDF5 Virtual Dataset that references a sensitive external file and publishes or sends it as a normal-looking model artifact.

AML.T0010.003

User Execution

Victim downloads the model and loads it via keras.models.load_model() or keras.saving.load_model() in their normal environment.

AML.T0011.000

Exploitation

Keras's H5IOStore._verify_dataset() fails to check dataset.is_virtual, so it transparently dereferences the VDS and reads the referenced external file's contents.

AML.T0037

Impact

The disclosed file contents (potentially credentials, configs, or other sensitive data) become accessible to or exfiltratable by the adversary.

AML.T0025

Staging

Adversary crafts a malicious .keras or .h5 file embedding an HDF5 Virtual Dataset that references a sensitive external file and publishes or sends it as a normal-looking model artifact.

AML.T0010.003

User Execution

Victim downloads the model and loads it via keras.models.load_model() or keras.saving.load_model() in their normal environment.

AML.T0011.000

Exploitation

Keras's H5IOStore._verify_dataset() fails to check dataset.is_virtual, so it transparently dereferences the VDS and reads the referenced external file's contents.

AML.T0037

Impact

The disclosed file contents (potentially credentials, configs, or other sensitive data) become accessible to or exfiltratable by the adversary.

AML.T0025

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Keras	pip	< 3.12.3	`3.12.3`
64.2K OpenSSF 7.1 1.6K dependents Pushed 3d ago 59% patched ~50d to patch Full package profile →

Do you use Keras? You're affected.

How severe is it?

CVSS 3.1

5.5 / 10

EPSS

0.1%

chance of exploitation in 30 days

Higher than 3% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Moderate

Exploitation Confidence

medium

○ CISA SSVC: Public PoC

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV Local

AC Low

PR None

UI Required

S Unchanged

C High

I None

A None

What should I do?

1 step

Upgrade to Keras 3.14.1, or 3.12.2 if pinned to the legacy 3.12.x branch. Until patched, do not load .keras or .h5 files from untrusted or unverified sources (public hubs, email attachments, unreviewed PRs); verify checksums/signatures on model artifacts where possible. Load any externally-sourced model in a sandboxed, least-privilege container with restricted filesystem access (no mounted secrets, read-only home directory) so a successful VDS reference has nothing sensitive to reach. Add file-access monitoring/EDR alerting for unexpected reads of credential files or config directories during model-loading processes. Where feasible, prefer safetensors or other formats without embedded external-file-reference capabilities for artifacts of unknown provenance.

What does CISA's SSVC say?

Decision Track*

Exploitation poc

Automatable No

Technical Impact partial

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

How is it classified?

Data Leakage Supply Chain Privacy Violation Model Training Data AML.T0010.003 - Model AML.T0011 - User Execution AML.T0011.000 - Unsafe AI Artifacts AML.T0037 - Data from Local System

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.6 - AI system verification and validation

NIST AI RMF

MANAGE-2.3 - Third-party AI resources are monitored and evaluated for risk on an ongoing basis

OWASP LLM Top 10

LLM05 - Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2026-12480?

Keras's earlier fix for a file-disclosure bug (CVE-2026-1669) turned out to be incomplete: versions through 3.13.2 still fail to check whether an HDF5 dataset is a Virtual Dataset (VDS), so a crafted .keras or .h5 file can embed a reference to any other file on the victim's filesystem. When a user simply calls keras.models.load_model() or keras.saving.load_model() on that file, Keras transparently dereferences the VDS and reads the external file's contents — no warning, no sandbox. There's no CVSS score, EPSS data, or CISA KEV listing yet, and no public exploit or scanner template has surfaced, so this isn't an active-exploitation emergency, but the attack surface is wide: Keras models are routinely pulled from public hubs, shared between teams, and loaded in CI/CD and notebooks with minimal scrutiny of the file's origin. Patch to Keras 3.14.1 (or 3.12.2 on the legacy branch) as soon as it fits your release cycle, and in the meantime treat any .keras/.h5 file from outside your organization as untrusted — load it only in an isolated, least-privilege environment.

Is CVE-2026-12480 actively exploited?

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

How to fix CVE-2026-12480?

Upgrade to Keras 3.14.1, or 3.12.2 if pinned to the legacy 3.12.x branch. Until patched, do not load .keras or .h5 files from untrusted or unverified sources (public hubs, email attachments, unreviewed PRs); verify checksums/signatures on model artifacts where possible. Load any externally-sourced model in a sandboxed, least-privilege container with restricted filesystem access (no mounted secrets, read-only home directory) so a successful VDS reference has nothing sensitive to reach. Add file-access monitoring/EDR alerting for unexpected reads of credential files or config directories during model-loading processes. Where feasible, prefer safetensors or other formats without embedded external-file-reference capabilities for artifacts of unknown provenance.

What systems are affected by CVE-2026-12480?

This vulnerability affects the following AI/ML architecture patterns: model loading pipelines, model registries/hubs, training pipelines, MLOps CI/CD workflows.

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

CVE-2026-12480 has a CVSS v3.1 base score of 5.5 (MEDIUM). The EPSS exploitation probability is 0.13%.

What is the AI security impact?

Affected AI Architectures

model loading pipelinesmodel registries/hubstraining pipelinesMLOps CI/CD workflows

MITRE ATLAS Techniques

AML.T0010.003 Model

AML.T0011 User Execution

AML.T0011.000 Unsafe AI Artifacts

AML.T0037 Data from Local System

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2.6

NIST AI RMF: MANAGE-2.3

OWASP LLM Top 10: LLM05

What are the technical details?

Original Advisory

Keras versions up to and including 3.13.2 are vulnerable to an arbitrary HDF5 file read due to an incomplete fix for CVE-2026-1669. The vulnerability resides in the `H5IOStore._verify_dataset()` and `file_editor.py` methods, which fail to check the `dataset.is_virtual` property of HDF5 datasets. This allows an attacker to craft a malicious `.keras` model archive or `.h5` weights file containing a Virtual Dataset (VDS) that references external HDF5 files on the victim's filesystem. When the victim loads the model using `keras.models.load_model()` or `keras.saving.load_model()`, the external file is transparently read, leading to potential information disclosure. Fixed in versions 3.12.2 and 3.14.1.

Exploitation Scenario

An adversary publishes a poisoned .keras model to a public model-sharing site or repo, disguised as a popular fine-tuned checkpoint, with an embedded HDF5 Virtual Dataset pointing at a sensitive local path such as ~/.aws/credentials, a CI secrets file, or /etc/shadow. A victim ML engineer downloads the model for evaluation and runs keras.models.load_model() in their normal working environment. Keras dereferences the VDS during load, reading the external file's bytes into the loaded object; the content may then surface via error messages, model introspection, or logging, and — if the loading happens inside a shared notebook, service response, or reported bug — flow back to the attacker.

Weaknesses (CWE)

CWE-73 External Control of File Name or Path Primary CWE-73 External Control of File Name or Path Primary CWE-73 External Control of File Name or Path

CWE-73 — External Control of File Name or Path: The product allows user input to control or influence paths or file names that are used in filesystem operations.

[Architecture and Design] When the set of filenames is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames, and reject all other inputs. For example, ID 1 could map to "inbox.txt" and ID 2 could map to "profile.txt". Features such as the ESAPI AccessReferenceMap provide this capability.
[Architecture and Design, Operation] Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict all access to files within a particular directory. Examples include the Unix chroot jail and AppArmor. In general, managed code may provide some protection. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.

Source: MITRE CWE corpus.