CVE-2026-120756 in HDF5
Summary
by MITRE • 11/03/2026
HDF5 through 2.2.0 contains a heap buffer over-read vulnerability in H5O__chunk_deserialize() in src/H5Ocache.c. When decoding object header messages, the declared message size is checked against the end of the chunk image before the remainder of the message header (flags, and for version 2 object headers, the optional creation index) has been decoded. Because the message body begins after these fields, a message can start up to four bytes further into the chunk than the size check accounts for. A crafted HDF5 file can declare a message size that passes the check but extends past the end of the chunk image, causing the message’s decode callback, for example H5O__mtime_new_decode() in src/H5Omtime.c, to read beyond the heap allocation. The flaw is reachable during H5Fopen() on a crafted file. An attacker who can get a user or application to open a malicious file can cause a denial of service or limited disclosure of process memory.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/03/2026
The vulnerability identified in HDF5 versions up to 2.2.0 represents a critical heap buffer over-read flaw located within the H5O__chunk_deserialize function found in src/H5Ocache.c. This component is responsible for decoding object header messages, which are fundamental structures used by the Hierarchical Data Format library to store metadata and data organization information. The core technical deficiency arises from an incorrect boundary check during the parsing process. Specifically, when a chunk image is being decoded, the software validates that the declared size of a message does not exceed the end of the available chunk data. However, this validation occurs before the system has processed additional header fields such as flags and, for version 2 object headers, optional creation indices. These fields occupy space within the message structure but are accounted for after the initial size check is performed. Consequently, there is a discrepancy between where the actual message body begins and where the safety boundary was established.
This logic error allows a crafted HDF5 file to declare a message size that technically passes the validation check yet effectively extends beyond the allocated heap memory boundaries once the full header structure is considered. Because the message body starts further into the chunk than the initial size limit accounts for, subsequent decoding callbacks are triggered with an incorrect pointer offset. For instance, functions like H5O__mtime_new_decode in src/H5Omtime.c may be invoked to process metadata such as modification times. When these callbacks attempt to read data based on the flawed pointers, they access memory locations outside the bounds of the heap allocation intended for that specific chunk image. This constitutes a classic out-of-bounds read vulnerability where the application reads sensitive or arbitrary memory contents rather than crashing immediately due to an invalid write operation.
The operational impact of this flaw is significant because it can be triggered simply by opening a malicious file using standard HDF5 functions such as H5Fopen(). An attacker who can persuade a user or automated system to open a specially crafted HDF5 file can exploit this condition. The primary consequence is a denial of service, typically manifesting as an application crash due to segmentation faults when the operating system detects illegal memory access. Beyond availability issues, there is a risk of limited information disclosure. By carefully crafting the payload and analyzing subsequent behavior or error messages, an attacker might be able to leak portions of process memory that contain sensitive data, such as encryption keys, session tokens, or other confidential information residing in adjacent heap regions. This transforms what appears to be a simple parsing bug into a potential vector for remote code execution precursors or significant privacy breaches depending on the context in which HDF5 is deployed.
From a classification perspective, this vulnerability aligns with CWE-126, Buffer Over-read, as it involves reading beyond allocated buffer boundaries. It also relates to CWE-20, Improper Input Validation, because the software fails to correctly validate that all components of the message structure fit within the expected memory limits before proceeding with decoding operations. In terms of attack vectors and techniques, this flaw is exploitable via ATT&CK technique T1553, Subvert Trust Controls, specifically through code signing or file format manipulation if the application trusts input from unverified sources without rigorous sanitization. It also falls under T1059, Command and Scripting Interpreter, in scenarios where memory disclosure aids further exploitation steps.
Mitigation strategies for this vulnerability require both immediate patching and long-term defensive coding practices. The most effective remediation is to upgrade the HDF5 library to a version newer than 2.2.0, where developers have corrected the order of operations in H5O__chunk_deserialize to ensure that all header fields are accounted for before validating message boundaries against chunk limits. For environments unable to patch immediately, input validation should be strengthened at the application layer by implementing strict file format checks and limiting the complexity of object headers accepted from untrusted sources. Additionally, enabling Address Sanitizer during development and testing phases can help detect such off-by-one or boundary errors early in the software lifecycle. Organizations relying on HDF5 for scientific data processing must ensure their dependency management systems are configured to automatically update to secure versions to prevent exploitation through maliciously crafted datasets.