CVE-2026-31971: HTSlib Buffer Overflow Vulnerability

CVE-2026-31971 Overview

CVE-2026-31971 is a buffer overflow vulnerability in HTSlib, a widely-used C library for reading and writing bioinformatics file formats including SAM, BAM, CRAM, and VCF. The vulnerability exists in the CRAM file format decoder, specifically in the cram_byte_array_len_decode() function which handles data encoded using the BYTE_ARRAY_LEN method. When processing maliciously crafted CRAM files, the decoder fails to validate that the amount of data being unpacked matches the size of the output buffer, potentially leading to heap or stack buffer overflows with attacker-controlled bytes.

Critical Impact
Exploitation of this vulnerability can lead to program crashes, heap or stack data corruption, control flow hijacking, and potentially arbitrary code execution when a user opens a maliciously crafted CRAM file.

Affected Products

HTSlib versions prior to 1.21.1
HTSlib versions 1.22.x prior to 1.22.2
HTSlib version 1.23 (prior to 1.23.1)

Discovery Timeline

2026-03-18 - CVE CVE-2026-31971 published to NVD
2026-03-19 - Last updated in NVD database

Technical Details for CVE-2026-31971

Vulnerability Analysis

The vulnerability is classified as CWE-121 (Stack-based Buffer Overflow). The flaw resides in the CRAM codec implementation, which handles compressed DNA sequence alignment data. CRAM files use various encoding and compression methods to efficiently store genomic data, and the BYTE_ARRAY_LEN encoding method is one such technique that stores variable-length byte arrays.

The vulnerable cram_byte_array_len_decode() function processes length-prefixed byte arrays without properly validating that the declared length fits within the allocated output buffer. An attacker can craft a malicious CRAM file that specifies a length value larger than the destination buffer, causing the decoder to write beyond buffer boundaries. Depending on which data series is being decoded, this overflow can occur either on the heap or the stack, providing different exploitation primitives.

Root Cause

The root cause is a missing bounds check in cram_byte_array_len_decode() within cram/cram_codecs.c. The original implementation decoded the length field and immediately proceeded to copy data without validating that:

The length value is non-negative
The length does not exceed the available output buffer size (out_size)

This lack of validation allows attacker-controlled length values to trigger buffer overflows when processing the associated byte array data.

Attack Vector

The attack requires user interaction—specifically, the victim must open a maliciously crafted CRAM file using an application that relies on HTSlib for CRAM parsing. This could include popular bioinformatics tools such as samtools, bcftools, or any genomic analysis pipeline that processes CRAM files from untrusted sources. The network attack vector indicates that files could be delivered via web downloads, email attachments, or shared research data repositories.

// Vulnerable code flow in cram_byte_array_len_decode() (pre-patch)
// Source: https://github.com/samtools/htslib/commit/01cd003b46fa2ebea4d9be5475b11217eb4c11be

    int32_t len = 0, one = 1;
    int r;

-    r = c->u.byte_array_len.len_codec->decode(slice, c->u.byte_array_len.len_codec,
-                                              in, (char *)&len, &one);
-    //printf("ByteArray Len=%d\n", len);
-
-    if (!r && c->u.byte_array_len.val_codec && len >= 0) {
-        r = c->u.byte_array_len.val_codec->decode(slice,
-                                                  c->u.byte_array_len.val_codec,
-                                                  in, out, &len);
+    cram_codec *len_codec = c->u.byte_array_len.len_codec;
+    cram_codec *val_codec = c->u.byte_array_len.val_codec;
+
+    r = len_codec->decode(slice, len_codec, in, (char *)&len, &one);
+    if (len < 0 || (len > *out_size &&
+                    !(val_codec->codec == E_EXTERNAL &&
+                      val_codec->u.external.type == E_BYTE_ARRAY_BLOCK))) {
+        fprintf(stderr, "Attempted overrun detected in %s\n", __FUNCTION__);
+        return -1;
+    }
+
+    if (!r && val_codec) {
+        r = val_codec->decode(slice, val_codec, in, out, &len);
     } else {
         return -1;
     }

Source: GitHub Commit Update

Detection Methods for CVE-2026-31971

Indicators of Compromise

Unexpected crashes in applications using HTSlib when processing CRAM files
Segmentation faults or access violations in cram_byte_array_len_decode() or related CRAM decoding functions
Memory corruption artifacts or unexpected behavior following CRAM file processing
Error messages indicating buffer overrun attempts (in patched versions)

Detection Strategies

Monitor application logs for crash reports involving HTSlib CRAM decoding functions
Implement file integrity validation for CRAM files received from external sources
Deploy endpoint detection and response (EDR) solutions capable of detecting heap/stack overflow exploitation patterns
Use static analysis tools to identify applications linked against vulnerable HTSlib versions

Monitoring Recommendations

Track HTSlib library versions deployed across bioinformatics infrastructure
Establish baselines for normal CRAM file processing behavior to detect anomalies
Monitor for unusual process behavior following CRAM file access, such as unexpected network connections or child process spawning
Implement CRAM file source validation and sandboxing for untrusted genomic data

How to Mitigate CVE-2026-31971

Immediate Actions Required

Upgrade HTSlib to version 1.23.1, 1.22.2, or 1.21.1 depending on your current version branch
Audit systems to identify all applications and pipelines dependent on HTSlib
Avoid processing CRAM files from untrusted or unverified sources until patching is complete
Consider isolating bioinformatics workloads that process external data in sandboxed environments

Patch Information

HTSlib maintainers have released patched versions that add proper bounds checking to the cram_byte_array_len_decode() function. The fix validates that the decoded length value is non-negative and does not exceed the output buffer size before proceeding with data copy operations. The patch also includes additional helper functions like aux_ele_size() to properly calculate element sizes for auxiliary data types.

Patched versions:

HTSlib 1.23.1 (for users on the 1.23.x branch)
HTSlib 1.22.2 (for users on the 1.22.x branch)
HTSlib 1.21.1 (for users on the 1.21.x branch)

Review the GitHub Security Advisory for complete details.

Workarounds

There is no workaround for this vulnerability—patching is required
As a temporary measure, avoid processing CRAM files from untrusted sources
Consider converting untrusted CRAM files to BAM format using trusted tools before processing
Implement network-level filtering to quarantine incoming CRAM files for manual review

bash

# Verify HTSlib version and update
# Check current HTSlib version
htsfile --version

# Update HTSlib on Debian/Ubuntu systems
sudo apt update && sudo apt install libhts-dev

# Or compile from source with the patched version
git clone https://github.com/samtools/htslib.git
cd htslib
git checkout 1.23.1
make && sudo make install