HTSlib CVE-2026-116742

Exploitation requires a victim to locally load an attacker-controlled .gzi BGZF index file (via the bgzf_index_load_hfile code path) using an HTSlib-based tool such as samtools or bcftools, then perform a seek that invokes bgzf_useek(). The specific trigger is a .gzi index whose stored entry count is 0xFFFFFFFF (or any value that truncates in the 32-bit int noffs/moffs fields to zero), which collapses the allocation to malloc(0). Limiting factors: the vector is LOCAL (AV:L) - the attacker cannot reach this remotely - and requires passive user interaction (UI:P), i.e. the victim must choose to process the malicious index/data file; impact is confined to Low integrity and availability (heap corruption/crash) with no confidentiality impact and no confirmed code execution. Only deployments that read .gzi index files are affected.

This is a low-to-moderate real-world risk despite the alarming 'heap out-of-bounds write' phrasing. The CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:N/UI:P) is explicitly LOCAL with passive user interaction and only Low vulnerable-system integrity and availability impact (VC:N/VI:L/VA:L), yielding a modest 4.8 base score - there is no confidentiality impact and no code-execution claim in the evidence, only heap corruption or crashes. The exploitation signals reinforce a non-urgent posture: EPSS is 0.12% (2nd percentile), the CVE is NOT on CISA KEV (no active exploitation), and the vuln.today Decision label is 'this_month' rather than act_now/emergency. A public PoC reference exists (the hackmd writeup by @haindpwn) and VulnCheck published an advisory, but the input does not confirm working exploit code; it is not verified as a weaponized exploit. The signals are consistent rather than conflicting: low EPSS, no KEV, low technical impact, and a local file-parsing vector all point to this being a 'patch in routine cycle' issue rather than a drop-everything emergency. The main caveat is that CWE-197 (numeric truncation) producing an OOB heap write past a malloc(0) buffer could in principle be escalated beyond a crash, but the evidence describes the outcome as heap corruption/crashes only.

An attacker crafts a malicious .gzi BGZF index file whose entry count field is set to 0xFFFFFFFF; the 32-bit value truncates noffs to zero, so a malloc(0) buffer is allocated and subsequent index entries are written past it, with bgzf_useek() also performing an offs[-1] read. When a victim runs a tool such as samtools or bcftools that loads this crafted index alongside a data file, the heap is corrupted, typically crashing the process. A public PoC reference exists (hackmd writeup); it is not verified as working exploit code, and exploitation requires the victim to locally process attacker-supplied index/data files.