evil-hdf5-numpy-opaque-poc

evil-hdf5-numpy-opaque-poc

Security research proof-of-concept — DO NOT LOAD on a machine you care about. Reading evil.h5 with default h5py crashes the Python process (SIGSEGV).

This repository contains a single crafted HDF5 file (evil.h5) demonstrating a memory-corruption vulnerability in h5py (the standard Python HDF5 loader). It is uploaded solely as the proof-of-concept artifact for a huntr Model File Vulnerability (MFV) report against the HDF5 target.

What it is

evil.h5 is a valid HDF5 file (magic 894844460d0a1a0a, h5py.is_hdf5() → True) containing one dataset named evil. The dataset's stored datatype is an H5T_OPAQUE type (itemsize 8) whose tag is NUMPY:|O. When h5py reads this dataset it reconstructs a NumPy object dtype from the attacker-controlled tag and memcpys the file's raw 8-byte values directly into PyObject* slots, causing a controlled fake-pointer dereference.

How to reproduce (in a disposable VM/container)

import h5py
with h5py.File("evil.h5", "r") as f:
    print(f["evil"].dtype)   # -> object
    f["evil"][...]           # -> SIGSEGV (exit code 139) on default h5py 3.16.0

Tested: h5py 3.16.0, numpy 2.2.6, CPython 3.10. The payload bytes (0x4141414141414141, …, 0xDEADBEEFDEADBEEF) are attacker-chosen; a NULL payload instead decodes to None without crashing, proving the dereferenced pointer is attacker-controlled.

Affected

• Package: h5py (pypi), version 3.16.0 (latest), git HEAD 88ff342.
• Root cause: asymmetric validation — opaque_dtype() rejects object dtype on write, but TypeOpaqueID.py_dtype() reconstructs it on read with no guard.

Full technical write-up and CWE/CVSS are in the accompanying huntr report.