CVE-2026-116742 in Htslib
Summary
by MITRE • 10/27/2026
HTSlib through 1.24 contains a heap out-of-bounds write and read vulnerability in bgzf_index_load_hfile() in bgzf.c that allows attackers to corrupt heap memory by supplying a crafted .gzi index entry count. A count of 0xFFFFFFFF truncates noffs to zero, causing writes past a malloc(0) buffer and an offs[-1] read in bgzf_useek(), resulting in heap corruption or crashes in tools like samtools and bcftools.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/27/2026
The vulnerability identified in HTSlib versions through 1.24 represents a critical memory safety failure within the background gzip file handling subsystem, specifically located in the bgzf_index_load_hfile function found in bgzf.c. This component is responsible for managing compressed genomic data formats commonly used in bioinformatics pipelines. The core technical flaw stems from an insufficient validation of integer values during the parsing of .gzi index files. When a maliciously crafted input supplies an entry count value of 0xFFFFFFFF, which corresponds to the maximum unsigned 32-bit integer, it triggers an arithmetic underflow or truncation error within the internal logic that calculates the number of offsets noffs. Instead of handling this extreme value gracefully or rejecting it as invalid, the code interprets the truncated result as zero. This misinterpretation leads directly to a subsequent allocation call using malloc with a size argument of zero.
The operational consequences of allocating a buffer with a size of zero are severe and well-documented in systems programming. Depending on the specific memory allocator implementation used by the underlying operating system, a request for zero bytes may return either NULL or a unique pointer that is valid but cannot be written to without causing undefined behavior. In this scenario, HTSlib proceeds as if it has successfully allocated space for index data structures. The code then attempts to write past the bounds of this effectively non-existent buffer and performs an offs[-1] read operation in the bgzf_useek function. This sequence results in a heap out-of-bounds write followed by a heap out-of-bounds read, allowing attackers who can influence the input .gzi index files to corrupt adjacent memory regions on the heap. Such corruption is particularly dangerous because it does not necessarily cause an immediate crash but rather creates unstable state that can be exploited for further attacks or lead to unpredictable application behavior later in execution.
The impact of this vulnerability extends beyond simple denial of service through crashes, although crashing tools like samtools and bcftools is a likely outcome when the memory corruption triggers segmentation faults or assertion failures. More critically, heap corruption provides an attack vector that could potentially be leveraged for arbitrary code execution if an attacker can carefully control the data written to adjacent heap structures. This aligns with common exploitation techniques where corrupted metadata such as size fields or function pointers in nearby allocations are manipulated to redirect program flow. The vulnerability is classified under CWE-787, which covers out-of-bounds write vulnerabilities, and also touches upon CWE-1342 for off-by-one errors that lead to buffer overflows. From a tactical perspective, this flaw relates to the ATT&CK technique of Taint and Probe or potentially Taint Commands if the corrupted memory leads to command injection in downstream processes, although its primary classification remains as an input validation failure leading to memory corruption.
Mitigation strategies for this vulnerability require both immediate patching and long-term defensive coding practices. The most effective remediation is to upgrade HTSlib to a version newer than 1.24 where the integer overflow has been addressed with proper bounds checking before any allocation or array indexing occurs. Developers should validate that index entry counts are within expected ranges for valid .gzi files, typically ensuring they do not exceed reasonable limits based on file size and structure constraints. For organizations unable to patch immediately, implementing input sanitization at the application layer is recommended. This involves validating all external inputs before passing them to HTSlib functions, specifically checking that integer values representing counts or sizes are within safe bounds. Additionally, enabling compiler protections such as stack canaries and using memory-safe languages for new development efforts can reduce the risk of exploitation from similar vulnerabilities in other components of bioinformatics software stacks.