Hi,
The following vulnerabilities were published for htslib.
CVE-2026-31962[0]:
| HTSlib is a library for reading and writing bioinformatics file
| formats. CRAM is a compressed format which stores DNA sequence
| alignment data. While most alignment records store DNA sequence and
| quality values, the format also allows them to omit this data in
| certain cases to save space. Due to some quirks of the CRAM format,
| it is necessary to handle these records carefully as they will
| actually store data that needs to be consumed and then discarded.
| Unfortunately the `cram_decode_seq()` did not handle this correctly
| in some cases. Where this happened it could result in reading a
| single byte from beyond the end of a heap allocation, followed by
| writing a single attacker-controlled byte to the same location.
| Exploiting this bug causes a heap buffer overflow. If a user opens a
| file crafted to exploit this issue, it could lead to the program
| crashing, or overwriting of data and heap structures in ways not
| expected by the program. It may be possible to use this to obtain
| arbitrary code execution. Versions 1.23.1, 1.22.2 and 1.21.1 include
| fixes for this issue. There is no workaround for this issue.
CVE-2026-31963[1]:
| HTSlib is a library for reading and writing bioinformatics file
| formats. CRAM is a compressed format which stores DNA sequence
| alignment data. As one method of removing redundant data, CRAM uses
| reference-based compression so that instead of storing the full
| sequence for each alignment record it stores a location in an
| external reference sequence along with a list of differences to the
| reference at that location as a sequence of "features". When
| decoding these features, an out-by-one error in a test for CRAM
| features that appear beyond the extent of the CRAM record sequence
| could result in an invalid write of one attacker-controlled byte
| beyond the end of a heap buffer. Exploiting this bug causes a heap
| buffer overflow. If a user opens a file crafted to exploit this
| issue, it could lead to the program crashing, or overwriting of data
| and heap structures in ways not expected by the program. It may be
| possible to use this to obtain arbitrary code execution. Versions
| 1.23.1, 1.22.2 and 1.21.1 include fixes for this issue. There is no
| workaround for this issue.
CVE-2026-31964[2]:
| HTSlib is a library for reading and writing bioinformatics file
| formats. CRAM is a compressed format which stores DNA sequence
| alignment data using a variety of encodings and compression methods.
| While most alignment records store DNA sequence and quality values,
| the format also allows them to omit this data in certain cases to
| save space. Due to some quirks of the CRAM format, it is necessary
| to handle these records carefully as they will actually store data
| that needs to be consumed and then discarded. Unfortunately the
| `CONST`, `XPACK` and `XRLE` encodings did not properly implement the
| interface needed to do this. Trying to decode records with omitted
| sequence or quality data using these encodings would result in an
| attempt to write to a NULL pointer. Exploiting this bug causes a
| NULL pointer dereference. Typically this will cause the program to
| crash. Versions 1.23.1, 1.22.2 and 1.21.1 include fixes for this
| issue. There is no workaround for this issue.
CVE-2026-31965[3]:
| HTSlib is a library for reading and writing bioinformatics file
| formats. CRAM is a compressed format which stores DNA sequence
| alignment data. In the `cram_decode_slice()` function called while
| reading CRAM records, validation of the reference id field occurred
| too late, allowing two out of bounds reads to occur before the
| invalid data was detected. The bug does allow two values to be
| leaked to the caller, however as the function reports an error it
| may be difficult to exploit them. It is also possible that the
| program will crash due to trying to access invalid memory. Versions
| 1.23.1, 1.22.2 and 1.21.1 include fixes for this issue. There is no
| workaround for this issue.
CVE-2026-31966[4]:
| HTSlib is a library for reading and writing bioinformatics file
| formats. CRAM is a compressed format which stores DNA sequence
| alignment data. As one method of removing redundant data, CRAM uses
| reference-based compression so that instead of storing the full
| sequence for each alignment record it stores a location in an
| external reference sequence along with a list of differences to the
| reference at that location as a sequence of "features". When
| decoding CRAM records, the reference data is stored in a char array,
| and parts matching the alignment record sequence are copied over as
| necessary. Due to insufficient validation of the feature data
| series, it was possible to make the `cram_decode_seq()` function
| copy data from either before the start, or after the end of the
| stored reference either into the buffer used to store the output
| sequence for the cram record, or into the buffer used to build the
| SAM `MD` tag. This allowed arbitrary data to be leaked to the
| calling function. This bug may allow information about program state
| to be leaked. It may also cause a program crash through an attempt
| to access invalid memory. Versions 1.23.1, 1.22.2 and 1.21.1 include
| fixes for this issue. There is no workaround for this issue.
CVE-2026-31967[5]:
| HTSlib is a library for reading and writing bioinformatics file
| formats. CRAM is a compressed format which stores DNA sequence
| alignment data. In the `cram_decode_slice()` function called while
| reading CRAM records, the value of the mate reference id field was
| not validated. Later use of this value, for example when converting
| the data to SAM format, could result in the out of bounds array
| reads when looking up the corresponding reference name. If the array
| value obtained also happened to be a valid pointer, it would be
| interpreted as a string and an attempt would be made to write the
| data as part of the SAM record. This bug may allow information about
| program state to be leaked. It may also cause a program crash
| through an attempt to access invalid memory. Versions 1.23.1, 1.22.2
| and 1.21.1 include fixes for this issue. There is no workaround for
| this issue.
CVE-2026-31968[6]:
| HTSlib is a library for reading and writing bioinformatics file
| formats. CRAM is a compressed format which stores DNA sequence
| alignment data using a variety of encodings and compression methods.
| For the `VARINT` and `CONST` encodings, incomplete validation of the
| context in which the encodings were used could result in up to eight
| bytes being written beyond the end of a heap allocation, or up to
| eight bytes being written to the location of a one byte variable on
| the stack, possibly causing the values to adjacent variables to
| change unexpectedly. Depending on the data stream this could result
| either in a heap buffer overflow or a stack overflow. If a user
| opens a file crafted to exploit this issue it could lead to the
| program crashing, overwriting of data structures on the heap or
| stack in ways not expected by the program, or changing the control
| flow of the program. It may be possible to use this to obtain
| arbitrary code execution. Versions 1.23.1, 1.22.2 and 1.21.1 include
| fixes for this issue. There is no workaround for this issue.
CVE-2026-31969[7]:
| HTSlib is a library for reading and writing bioinformatics file
| formats. CRAM is a compressed format which stores DNA sequence
| alignment data using a variety of encodings and compression methods.
| When reading data encoded using the `BYTE_ARRAY_STOP` method, an
| out-by-one error in the `cram_byte_array_stop_decode_char()`
| function check for a full output buffer could result in a single
| attacker-controlled byte being written beyond the end of a heap
| allocation. Exploiting this bug causes a heap buffer overflow. If a
| user opens a file crafted to exploit this issue, it could lead to
| the program crashing, or overwriting of data and heap structures in
| ways not expected by the program. It may be possible to use this to
| obtain arbitrary code execution. Versions 1.23.1, 1.22.2 and 1.21.1
| include fixes for this issue. There is no workaround for this issue.
CVE-2026-31970[8]:
| HTSlib is a library for reading and writing bioinformatics file
| formats. GZI files are used to index block-compressed GZIP [BGZF]
| files. In the GZI loading function, `bgzf_index_load_hfile()`, it
| was possible to trigger an integer overflow, leading to an under- or
| zero-sized buffer being allocated to store the index. Sixteen zero
| bytes would then be written to this buffer, and, depending on the
| result of the overflow the rest of the file may also be loaded into
| the buffer as well. If the function did attempt to load the data,
| it would eventually fail due to not reading the expected number of
| records, and then try to free the overflowed heap buffer. Exploiting
| this bug causes a heap buffer overflow. If a user opens a file
| crafted to exploit this issue, it could lead to the program
| crashing, or overwriting of data and heap structures in ways not
| expected by the program. It may be possible to use this to obtain
| arbitrary code execution. Versions 1.23.1, 1.22.2 and 1.21.1 include
| fixes for this issue. The easiest work-around is to discard any
| `.gzi` index files from untrusted sources, and use the `bgzip -r`
| option to recreate them.
CVE-2026-31971[9]:
| HTSlib is a library for reading and writing bioinformatics file
| formats. CRAM is a compressed format which stores DNA sequence
| alignment data using a variety of encodings and compression methods.
| When reading data encoded using the `BYTE_ARRAY_LEN` method, the
| `cram_byte_array_len_decode()` failed to validate that the amount of
| data being unpacked matched the size of the output buffer where it
| was to be stored. Depending on the data series being read, this
| could result either in a heap or a stack overflow with attacker-
| controlled bytes. Depending on the data stream this could result
| either in a heap buffer overflow or a stack overflow. If a user
| opens a file crafted to exploit this issue it could lead to the
| program crashing, overwriting of data structures on the heap or
| stack in ways not expected by the program, or changing the control
| flow of the program. It may be possible to use this to obtain
| arbitrary code execution. Versions 1.23.1, 1.22.2 and 1.21.1 include
| fixes for this issue. There is no workaround for this issue.
If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
For further information see:
[0] https://security-tracker.debian.org/tracker/CVE-2026-31962
https://www.cve.org/CVERecord?id=CVE-2026-31962
[1] https://security-tracker.debian.org/tracker/CVE-2026-31963
https://www.cve.org/CVERecord?id=CVE-2026-31963
[2] https://security-tracker.debian.org/tracker/CVE-2026-31964
https://www.cve.org/CVERecord?id=CVE-2026-31964
[3] https://security-tracker.debian.org/tracker/CVE-2026-31965
https://www.cve.org/CVERecord?id=CVE-2026-31965
[4] https://security-tracker.debian.org/tracker/CVE-2026-31966
https://www.cve.org/CVERecord?id=CVE-2026-31966
[5] https://security-tracker.debian.org/tracker/CVE-2026-31967
https://www.cve.org/CVERecord?id=CVE-2026-31967
[6] https://security-tracker.debian.org/tracker/CVE-2026-31968
https://www.cve.org/CVERecord?id=CVE-2026-31968
[7] https://security-tracker.debian.org/tracker/CVE-2026-31969
https://www.cve.org/CVERecord?id=CVE-2026-31969
[8] https://security-tracker.debian.org/tracker/CVE-2026-31970
https://www.cve.org/CVERecord?id=CVE-2026-31970
[9] https://security-tracker.debian.org/tracker/CVE-2026-31971
https://www.cve.org/CVERecord?id=CVE-2026-31971
Regards,
Salvatore