CVE-2026-12479: Keras path traversal

CISO Take

Keras 3.14.0 contains a path traversal flaw in its model serialization layer — the DiskIOStore.make method uses user-supplied layer names to construct filesystem paths without filtering directory traversal sequences (../), allowing a crafted model file to escape the intended temp directory and write files anywhere the process has permission. With 1,559 downstream package dependents, this vulnerability propagates across a wide swath of ML training and serving pipelines. No CVSS or public exploit exists yet, but CWE-22 path traversal is trivial to weaponize once the attack primitive is understood — any workflow that loads externally sourced Keras models from Hugging Face, internal registries, or researcher-shared checkpoints is directly exposed. Immediately restrict model loading to hash-verified, trusted sources and audit layer-name inputs pending a confirmed patched release.

Sources: NVD GitHub Advisory OpenSSF ATLAS

What is the risk?

Moderate risk overall, elevated in environments that load externally sourced models without integrity verification. The attack primitive — loading a crafted .keras file — is endemic to collaborative ML workflows and requires no AI expertise to exploit; a standard path traversal payload embedded in a layer name suffices. No CVSS has been assigned and the vulnerability is absent from CISA KEV, but the package carries 14 prior CVEs, a package risk score of 60/100, and 1,559 downstream dependents, indicating both a recurring security surface and wide blast radius. Exploitability is further amplified if arbitrary file writes reach Python site-packages, cron directories, or SSH authorized_keys paths, enabling privilege escalation beyond the immediate ML context.

How does the attack unfold?

Artifact Crafting

Adversary creates a structurally valid Keras 3 model file containing layers named with path traversal sequences (e.g., '../../target/path') designed to exploit DiskIOStore.make during save or load operations.

AML.T0018.002

Delivery via Model Registry

Malicious model is published to Hugging Face, an internal model registry, or shared directly with target data scientists or ML pipelines, bypassing surface-level validation.

AML.T0010.003

Exploitation on Load

Victim calls keras.saving.load_model(); DiskIOStore.make constructs filesystem paths from unsanitized layer names, escaping the intended temp directory without any exception or warning.

AML.T0011.000

Arbitrary File Write

Attacker achieves directory creation and file writes at arbitrary paths — potentially overwriting SSH authorized_keys, cron jobs, or Python package init files to establish persistence or escalate privileges on the ML host.

Artifact Crafting

Adversary creates a structurally valid Keras 3 model file containing layers named with path traversal sequences (e.g., '../../target/path') designed to exploit DiskIOStore.make during save or load operations.

AML.T0018.002

Delivery via Model Registry

Malicious model is published to Hugging Face, an internal model registry, or shared directly with target data scientists or ML pipelines, bypassing surface-level validation.

AML.T0010.003

Exploitation on Load

Victim calls keras.saving.load_model(); DiskIOStore.make constructs filesystem paths from unsanitized layer names, escaping the intended temp directory without any exception or warning.

AML.T0011.000

Arbitrary File Write

Attacker achieves directory creation and file writes at arbitrary paths — potentially overwriting SSH authorized_keys, cron jobs, or Python package init files to establish persistence or escalate privileges on the ML host.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Keras	pip	—	No patch
64.1K OpenSSF 7.1 1.6K dependents Pushed 3d ago 48% patched ~32d to patch Full package profile →

Do you use Keras? You're affected.

How severe is it?

CVSS 3.1

N/A

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Trivial

What should I do?

5 steps

Patch: Monitor keras-team/keras on GitHub and PyPI for a release beyond 3.14.0 that resolves this flaw; apply immediately upon availability.
Source restriction: Until patched, load .keras model files exclusively from trusted, cryptographically hash-verified sources — reject any model of unknown provenance.
Input validation: Add a pre-load validator that inspects model layer names and rejects any containing '..' or null bytes before passing to load_model().
Least privilege: Ensure ML training containers and model-serving processes run with minimal filesystem permissions scoped to their working directories so traversal impact is bounded.
Detection: Monitor for anomalous directory creation or file writes in parent directories relative to model temp paths during save/load operations using auditd, eBPF-based tools, or container runtime security policies.

How is it classified?

Supply Chain Code Execution Framework Model AML.T0010.001 - AI Software AML.T0010.003 - Model AML.T0011.000 - Unsafe AI Artifacts AML.T0018.002 - Embed Malware

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 9 - Risk management system

ISO 42001

A.9.6 - AI supply chain risk management

NIST AI RMF

MANAGE 2.4 - Risks from third-party entities

OWASP LLM Top 10

LLM05 - Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2026-12479?

Keras 3.14.0 contains a path traversal flaw in its model serialization layer — the DiskIOStore.make method uses user-supplied layer names to construct filesystem paths without filtering directory traversal sequences (../), allowing a crafted model file to escape the intended temp directory and write files anywhere the process has permission. With 1,559 downstream package dependents, this vulnerability propagates across a wide swath of ML training and serving pipelines. No CVSS or public exploit exists yet, but CWE-22 path traversal is trivial to weaponize once the attack primitive is understood — any workflow that loads externally sourced Keras models from Hugging Face, internal registries, or researcher-shared checkpoints is directly exposed. Immediately restrict model loading to hash-verified, trusted sources and audit layer-name inputs pending a confirmed patched release.

Is CVE-2026-12479 actively exploited?

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

How to fix CVE-2026-12479?

1. Patch: Monitor keras-team/keras on GitHub and PyPI for a release beyond 3.14.0 that resolves this flaw; apply immediately upon availability. 2. Source restriction: Until patched, load .keras model files exclusively from trusted, cryptographically hash-verified sources — reject any model of unknown provenance. 3. Input validation: Add a pre-load validator that inspects model layer names and rejects any containing '..' or null bytes before passing to load_model(). 4. Least privilege: Ensure ML training containers and model-serving processes run with minimal filesystem permissions scoped to their working directories so traversal impact is bounded. 5. Detection: Monitor for anomalous directory creation or file writes in parent directories relative to model temp paths during save/load operations using auditd, eBPF-based tools, or container runtime security policies.

What systems are affected by CVE-2026-12479?

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

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

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

training pipelinesmodel servingMLOps pipelinesmodel registries

MITRE ATLAS Techniques

AML.T0010.001 AI Software

AML.T0010.003 Model

AML.T0011.000 Unsafe AI Artifacts

AML.T0018.002 Embed Malware

Compliance Controls Affected

EU AI Act: Article 9

ISO 42001: A.9.6

NIST AI RMF: MANAGE 2.4

OWASP LLM Top 10: LLM05

What are the technical details?

Original Advisory

A path traversal vulnerability exists in keras-team/keras version 3.14.0, specifically in the `DiskIOStore.make` method within the Keras 3 model saving and loading library. This vulnerability arises from the improper handling of user-provided layer names, which are used to construct directory paths without sanitizing for parent directory components (`..`). While forward slashes (`/`) are restricted in layer names, directory traversal sequences are not. This allows an attacker to craft a malicious Keras model that, when saved or loaded, can escape the intended temporary working directory and perform unauthorized file system operations, such as creating directories or writing files in arbitrary locations.

Exploitation Scenario

An adversary publishes a malicious Keras 3 image-classification or fine-tuned LLM adapter model to Hugging Face or a company's internal model registry. The model is structurally valid and passes surface-level review, but contains layers named with traversal sequences such as '../../home/mluser/.ssh/' or '../../opt/conda/lib/python3.11/site-packages/keras/'. When a data scientist or an automated CI/CD pipeline calls keras.saving.load_model() on this file, DiskIOStore.make constructs unsanitized paths from the layer names, silently creating directories or writing attacker-controlled files outside the temp working directory — overwriting SSH authorized_keys for persistent access or injecting malicious code into Keras itself to backdoor subsequent model loads across the environment.

Weaknesses (CWE)

CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

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.