Live › vulnerability › CVE-2026-120755
HDF5 through 2.2.0 subtracts a 4-byte header from a szip chunk length without checking the chunk is at least 4 bytes, so a truncated chunk wraps the length and the decompressor reads past the buffer. An attacker who gets a user or application to open a crafted HDF5 file can cause a denial of service.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-11-03 16:21 UTC. All times on this page are UTC.
Only builds of HDF5 with szip support (libaec or the szip library) are affected, and the trigger is reading a dataset from a crafted or corrupted file. Teams that only read trusted, self-generated HDF5 files face lower risk. The sources do not state a fixed version.
No product ranges from the sources yet.
2.2.0 or earlier.No fix yet, per the sources.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
HDF5 through 2.2.0 contains an out-of-bounds read vulnerability in H5Z__filter_szip() in src/H5Zszip.c. When decoding a szip-compressed chunk, the function subtracts the 4-byte uncompressed-length header from the chunk length without first verifying that the chunk is at least 4 bytes long. A truncated or corrupted chunk shorter than the header causes the length calculation to wrap around to a very large value, and the decompressor reads far past the end of the chunk buffer. An attacker who can get a user or application to read a dataset from a crafted HDF5 file can cause a denial of service. Only builds with szip support (libaec or the szip library) are affected.
This page as .md · .json · in your agent: get_signal("CVE-2026-120755")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.