CVE-2026-12570: Keras OOM DoS — MEDIUM

Q: What is CVE-2026-12570?

A flaw in Keras (<=3.15.0) lets a specially crafted .keras model file trigger unbounded memory allocation when loaded via keras.models.load_model(), because the H5IOStore.__getitem__ method never validates dataset shape or size before allocating buffers for it — the process OOMs and is killed (exit 137). This matters because the attack vector is a poisoned model uploaded to a public repository or model registry, meaning any ML pipeline that pulls third-party models can be crashed simply by ingesting one; it also quietly bypasses the fix shipped for CVE-2026-0897, which only closed this class of bug in KerasFileEditor and missed the loader path. There's no CVSS score, no CISA KEV listing, no public exploit or Nuclei template yet, and EPSS sits at a low 0.00128, so exploitation is not currently observed in the wild — CISA's SSVC decision of TRACK_STAR reflects that this is worth watching but not an immediate fire drill. Still, denial of service against training or inference pipelines that auto-ingest models is a real availability risk, especially in CI/CD or MLOps flows with weak provenance controls. Upgrade to the patched Keras release incorporating commit 4933ea4, and in the meantime enforce memory/resource limits (cgroups, ulimits, container quotas) around any process that calls load_model() on untrusted files, restrict model sources to vetted registries, and alert on repeated OOM-kills (exit 137) in ML pipeline logs.

Q: Is CVE-2026-12570 actively exploited?

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

Q: How to fix CVE-2026-12570?

Upgrade Keras past the version containing the fix referenced in commit 4933ea4a5b3fcc24ceacdc276f5bb5dfbd06756c (verify the patched release once cut, since no fixed version number is published in this advisory). Until patched, treat any .keras file from outside your organization as untrusted: only load models from vetted, internally-controlled registries with provenance/signing, never load models fetched directly from public hubs into production-critical or unthrottled processes. Run model-loading code inside resource-bounded environments (container memory limits, cgroups, ulimit -v) so an OOM kills a sandboxed worker rather than a shared host or orchestrator node. Add monitoring/alerting for repeated OOM-kills (exit code 137) on ML pipeline or serving processes, which is the primary detection signal for this class of attack. Track upstream Keras security advisories for the definitive patched version.

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

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

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

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

CISO Take

A flaw in Keras (<=3.15.0) lets a specially crafted .keras model file trigger unbounded memory allocation when loaded via keras.models.load_model(), because the H5IOStore.__getitem__ method never validates dataset shape or size before allocating buffers for it — the process OOMs and is killed (exit 137). This matters because the attack vector is a poisoned model uploaded to a public repository or model registry, meaning any ML pipeline that pulls third-party models can be crashed simply by ingesting one; it also quietly bypasses the fix shipped for CVE-2026-0897, which only closed this class of bug in KerasFileEditor and missed the loader path. There's no CVSS score, no CISA KEV listing, no public exploit or Nuclei template yet, and EPSS sits at a low 0.00128, so exploitation is not currently observed in the wild — CISA's SSVC decision of TRACK_STAR reflects that this is worth watching but not an immediate fire drill. Still, denial of service against training or inference pipelines that auto-ingest models is a real availability risk, especially in CI/CD or MLOps flows with weak provenance controls. Upgrade to the patched Keras release incorporating commit 4933ea4, and in the meantime enforce memory/resource limits (cgroups, ulimits, container quotas) around any process that calls load_model() on untrusted files, restrict model sources to vetted registries, and alert on repeated OOM-kills (exit 137) in ML pipeline logs.

Sources: NVD GitHub Advisory EPSS ATLAS huntr.com

What is the risk?

Low-to-moderate risk today: this is an unauthenticated, low-complexity denial-of-service bug (CWE-770, uncontrolled resource allocation) with no confirmed CVSS score, no CISA KEV listing, and no public exploit code or scanner template. EPSS is low (0.00128), and CISA's SSVC verdict (TRACK_STAR) confirms it doesn't meet the bar for urgent action — but it's flagged for tracking because it defeats a prior fix (CVE-2026-0897) and the attack surface (loading arbitrary third-party model files) is common in ML workflows. The impact is availability-only (process crash), not confidentiality or integrity, which caps the ceiling of harm to service disruption and pipeline downtime rather than data compromise.

How does the attack unfold?

Publish poisoned model

Adversary crafts a .keras file with a dataset declaring an oversized shape and uploads it to a public model repository or registry, disguised as a legitimate model.

AML.T0010.003

Victim loads the model

A data scientist or automated ML pipeline downloads the file and calls keras.models.load_model() to use it.

AML.T0011.000

Unbounded allocation triggered

H5IOStore.__getitem__ reads the unvalidated declared size and allocates memory for it without bounds-checking.

AML.T0076

Denial of service

The process exhausts available memory and is OOM-killed (exit 137), disrupting the training, CI, or inference pipeline.

AML.T0029

Publish poisoned model

Adversary crafts a .keras file with a dataset declaring an oversized shape and uploads it to a public model repository or registry, disguised as a legitimate model.

AML.T0010.003

Victim loads the model

A data scientist or automated ML pipeline downloads the file and calls keras.models.load_model() to use it.

AML.T0011.000

Unbounded allocation triggered

H5IOStore.__getitem__ reads the unvalidated declared size and allocates memory for it without bounds-checking.

AML.T0076

Denial of service

The process exhausts available memory and is OOM-killed (exit 137), disrupting the training, CI, or inference pipeline.

AML.T0029

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Keras	pip	< 3.15.0	`3.15.0`
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

5.5 / 10

EPSS

0.1%

chance of exploitation in 30 days

Higher than 2% 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 None

I None

A High

What should I do?

1 step

Upgrade Keras past the version containing the fix referenced in commit 4933ea4a5b3fcc24ceacdc276f5bb5dfbd06756c (verify the patched release once cut, since no fixed version number is published in this advisory). Until patched, treat any .keras file from outside your organization as untrusted: only load models from vetted, internally-controlled registries with provenance/signing, never load models fetched directly from public hubs into production-critical or unthrottled processes. Run model-loading code inside resource-bounded environments (container memory limits, cgroups, ulimit -v) so an OOM kills a sandboxed worker rather than a shared host or orchestrator node. Add monitoring/alerting for repeated OOM-kills (exit code 137) on ML pipeline or serving processes, which is the primary detection signal for this class of attack. Track upstream Keras security advisories for the definitive patched version.

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?

DoS Supply Chain Framework Model AML.T0010.003 - Model AML.T0011.000 - Unsafe AI Artifacts AML.T0029 - Denial of AI Service AML.T0076 - Corrupt AI Model

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 operation and monitoring

NIST AI RMF

MEASURE 2.7 - AI system security and resilience evaluated and documented

OWASP LLM Top 10

LLM04:2025 - Model Denial of Service

Frequently Asked Questions

What is CVE-2026-12570?

A flaw in Keras (<=3.15.0) lets a specially crafted .keras model file trigger unbounded memory allocation when loaded via keras.models.load_model(), because the H5IOStore.__getitem__ method never validates dataset shape or size before allocating buffers for it — the process OOMs and is killed (exit 137). This matters because the attack vector is a poisoned model uploaded to a public repository or model registry, meaning any ML pipeline that pulls third-party models can be crashed simply by ingesting one; it also quietly bypasses the fix shipped for CVE-2026-0897, which only closed this class of bug in KerasFileEditor and missed the loader path. There's no CVSS score, no CISA KEV listing, no public exploit or Nuclei template yet, and EPSS sits at a low 0.00128, so exploitation is not currently observed in the wild — CISA's SSVC decision of TRACK_STAR reflects that this is worth watching but not an immediate fire drill. Still, denial of service against training or inference pipelines that auto-ingest models is a real availability risk, especially in CI/CD or MLOps flows with weak provenance controls. Upgrade to the patched Keras release incorporating commit 4933ea4, and in the meantime enforce memory/resource limits (cgroups, ulimits, container quotas) around any process that calls load_model() on untrusted files, restrict model sources to vetted registries, and alert on repeated OOM-kills (exit 137) in ML pipeline logs.

Is CVE-2026-12570 actively exploited?

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

How to fix CVE-2026-12570?

Upgrade Keras past the version containing the fix referenced in commit 4933ea4a5b3fcc24ceacdc276f5bb5dfbd06756c (verify the patched release once cut, since no fixed version number is published in this advisory). Until patched, treat any .keras file from outside your organization as untrusted: only load models from vetted, internally-controlled registries with provenance/signing, never load models fetched directly from public hubs into production-critical or unthrottled processes. Run model-loading code inside resource-bounded environments (container memory limits, cgroups, ulimit -v) so an OOM kills a sandboxed worker rather than a shared host or orchestrator node. Add monitoring/alerting for repeated OOM-kills (exit code 137) on ML pipeline or serving processes, which is the primary detection signal for this class of attack. Track upstream Keras security advisories for the definitive patched version.

What systems are affected by CVE-2026-12570?

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

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

CVE-2026-12570 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

training pipelinesmodel servingMLOps CI/CD pipelinesmodel registries/repositories

MITRE ATLAS Techniques

AML.T0010.003 Model

AML.T0011.000 Unsafe AI Artifacts

AML.T0029 Denial of AI Service

AML.T0076 Corrupt AI Model

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2.6

NIST AI RMF: MEASURE 2.7

OWASP LLM Top 10: LLM04:2025

What are the technical details?

Original Advisory

A vulnerability in keras-team/keras versions <= 3.15.0 allows for a denial of service (DoS) attack when loading malicious .keras model files via the keras.models.load_model() function. The H5IOStore.__getitem__ method in keras/src/saving/saving_lib.py does not validate the shape or size of datasets, leading to unbounded memory allocation. A specially crafted .keras file can exploit this flaw to trigger an out-of-memory (OOM) condition, causing the process to be terminated (exit code 137). This issue bypasses the fix for CVE-2026-0897, which only addressed a similar vulnerability in KerasFileEditor. The attack vector includes poisoned models from public repositories or malicious model registries, posing a risk to machine learning pipelines that process untrusted models.

Exploitation Scenario

An adversary crafts a .keras file (a zip-based HDF5 archive) in which a stored dataset declares an enormous shape/size without the underlying data actually being that large, then publishes it to a public model repository or registry — potentially disguised as a fine-tuned or optimized version of a popular model to encourage downloads. A data scientist or an automated MLOps pipeline downloads the file and calls keras.models.load_model() during training, evaluation, or CI validation. H5IOStore.__getitem__ reads the declared size and attempts to allocate memory for it without bounds-checking, exhausting available RAM and causing the OS to kill the process (OOM, exit 137). If this happens inside an auto-restarting service, the crash loop repeats each time the poisoned model is reloaded, producing a sustained denial of service against the ML pipeline or deployment.

Weaknesses (CWE)

CWE-770 Allocation of Resources Without Limits or Throttling Primary CWE-770 Allocation of Resources Without Limits or Throttling Primary CWE-770 Allocation of Resources Without Limits or Throttling

CWE-770 — Allocation of Resources Without Limits or Throttling: The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated.

[Requirements] Clearly specify the minimum and maximum expectations for capabilities, and dictate which behaviors are acceptable when resource allocation reaches limits.
[Architecture and Design] Limit the amount of resources that are accessible to unprivileged users. Set per-user limits for resources. Allow the system administrator to define these limits. Be careful to avoid CWE-410.

Source: MITRE CWE corpus.