Upgrade to release 1.23.5 with the following security issues:
- CVE-2026-XXXXX (GHSA-v8qw-hwjv-44hw) Memory exhaustion through a
mismatch between the container and the bitstream image size. A
crafted image can declare a small size in its ispe property while
the bitstream declares a much larger coded frame. The
container-level checks used the ispe size, so the oversized
bitstream reached the decoder, which allocated a frame buffer for
the in-band size before libheif rejected the mismatch. The
advisory demonstrated this for AV1 with the libaom backend (a
351-byte AVIF declaring 64x64 but coding up to 27648x27648,
allocating hundreds of MB to more than 10 GB), but the same class
affects every codec whose real frame size lives in the bitstream.
The coded size is now checked against max_image_size_pixels in
the codec-independent decode path, before any bytes reach a
decoder plugin: all AV1 sequence headers, all HEVC/AVC/VVC SPS
NAL units (including those carried in the item data, not only the
ones in the configuration record), the JPEG SOF marker and the
JPEG 2000 SIZ reference grid are scanned for the largest coded
size. (high)
- CVE-2026-XXXXX (GHSA-qwpf-5wf7-r996) Heap use-after-free and
double free when encoding an image that carries a TAI timestamp,
including transcoding a file with an itai property.
ImageDescription shallow-copied its raw heif_tai_timestamp_packet
pointer, and a temporary in ImageItem::encode_to_bitstream_and_boxes()
freed the packet while the item and the source image still held
it. The timestamp is now stored by value. (medium)
- CVE-2026-XXXXX (GHSA-9c75-9g8r-4728) Memory amplification through
a JPEG 2000 pclr box declaring zero palette columns. The
entry-count bound was skipped for zero columns, so an 11-byte box
allocated 65,535 empty palette entries, and nested j2kH containers
could repeat this within the child and nesting limits: a 3 KB file
reached about 330 MB RSS, none of it charged to max_total_memory.
Zero columns are rejected (ISO/IEC 15444-1 requires 1 to 255),
the byte bound is unconditional, and the palette storage is
charged to the memory limits. (medium)
- CVE-2026-XXXXX (GHSA-r7gr-2xm2-23wf) Heap out-of-bounds read in
alpha compositing for uncompressed (unci) images whose colour
planes have different bit depths. Op_flatten_alpha_plane read
every plane through the sample type of the first colour plane, so
an 8-bit blue plane next to 16-bit red and green planes was read
with a halved stride past its end, and the bytes ended up in the
composited output. ColorState now tracks one bit depth per plane,
and the operator declines mixed sample widths at planning time.
(medium)
- CVE-2026-XXXXX (GHSA-q492-cfcm-895h) The OpenJPEG decoder
plugin's pre-decode size check bounded the JPEG 2000 window span
(x1-x0)*(y1-y0) but not the absolute reference-grid coordinates,
so a codestream with a 17-pixel window on a grid near the 32-bit
boundary reached opj_decode(). Against OpenJPEG 2.3.1 this
produced a heap-buffer-overflow write inside OpenJPEG (the class
of CVE-2020-6851); OpenJPEG 2.5.4 rejects the input. The
reference-grid area is now bounded as well. (low)
- (GHSA-qfj5-c4pq-q998) Heap out-of-bounds read in the uncompressed
encoder when an application attached a separate alpha plane to an
image with an interleaved chroma format. The interleaved encoders
took their component list from the chroma format (three entries)
but decided whether to write alpha from the presence of an alpha
plane, and indexed the list at [3]. heif_image_add_plane() now
rejects a separate alpha plane on interleaved images, and the
encoders derive both decisions from the chroma format. Only
reachable through the public API; decoding never produces such an
image. (low)
- (GHSA-7pwf-qh74-p35w) The caller's heif_security_limits were not
applied when parsing a mini box (the MIAF minimized image format)
or the av1C/hvcC blob embedded in it; the built-in defaults were
used instead. An application that tightened the limits got no
enforcement of its max_memory_block_size or max_total_memory on
such files. The allocations are bounded by the bytes present in
the box, so this could not amplify memory use. (low)
This work was sponsored by GOVCERT.LU.
Signed-off-by: Leon Anavi <leon.anavi@konsulko.com>
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
Upgrade to release 1.23.1.
New features:
- FFmpeg decoder plugin gains AV1, VVC, JPEG, and JPEG 2000/HTJ2K
decoding
- SVT-AV1 encoder: new tune=iq and ms-ssim tune parameters
- C++ API: added getters/setters for the CLLI and MDCV HDR metadata
boxes
- Sequence decoder now scales the alpha auxiliary track to the main
image size
Bug fixes:
- Fixed pixi box writing for multi-channel images
- Corrected the placement of the TAI clock_type field into the top
2 bits
- Empty/unset plugin directory is no longer scanned
Security fixes:
- CVE-TBD (GHSA-jc8f-p23p-5hjg) Integer underflow in Fraction
constructor via double clap transform application
- CVE-TBD (GHSA-73p7-m7gg-w2jv) Out-of-bounds read in uncompressed
unci tile range slicing
= CVE-TBD (GHSA-xpw3-9rhw-482x) Heap out of bounds write in libheif
uncompressed encoder when writing images with mismatched
auxiliary alpha dimensions
- CVE-TBD (GHSA-9ww4-9v47-m7pj) Reachable assertion in
HeifContext::get_track() aborts on a valid-but-empty HEIF
sequence file
- (GHSA-46rp-pcq2-rpmr) Heap out-of-bounds write in the
uncompressed encoder for RRGGBB images with interleaved bit-depth
lower or equal to 8
Remove CVE-2026-3949.patch because the fix has been included in
the source code for this release of libheif.
This work was sponsored by GOVCERT.LU.
Signed-off-by: Leon Anavi <leon.anavi@konsulko.com>
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
Changelog:
1.21.2:
- build script for JS/WASM now supports building with JPEG2000
and "ISO23001-17 Uncompressed" support.
- image sequence SAI data now works when using the OpenH264 decoder plugin
1.21.1:
- This patch release only fixes a build error with some GCC versions
because of a missing #include.
1.21.0:
- CVE-2025-68431 fixed
- This release adds full support for reading and writing HEIF image sequences.
- libheif will now encode HEIF image sequences with all included codecs.
- Since HEIF image sequences are very similar to MP4 videos, this new version
is also capable of decoding most MP4 videos (without audio, of course).
- Support for image sequences with alpha channels. For most codecs, the alpha
channel will be stored in a separate, auxiliary, monochrome track. For
ISO/IEC 23001-17 (uncompressed) streams, the alpha channel is stored in
the main video track.
- Support for sequence track edit lists to define the number of sequence
repetitions (without actually repeating the video data).
- New encoder plugin using x264 to write H.264-compressed video streams and images.
- The FFmpeg decoder plugin will now decode both H.265 and H.264.
- Support for HEIF text items and language properties
Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Upgrade to release 1.20.2:
- When opening tiled images, do not check against maximum image size
immediately to allow for tile-based decoding of very large images.
- Several smaller fixes in writing image sequences
- CMake option to disable building of heif-view, which pulls in
dependency on SDL
- Fixes reading/writing of GIMI content IDs
- Some build fixes
This work was sponsored by GOVCERT.LU.
Signed-off-by: Leon Anavi <leon.anavi@konsulko.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Please see
https://git.yoctoproject.org/poky/commit/?id=4dd321f8b83afecd962393101b2a6861275b5265
for what changes are needed, and sed commands that can be used to make them en masse.
I've verified that bitbake -c patch world works with these, but did not run a world
build; the majority of recipes shouldn't need further fixups, but if there are
some that still fall out, they can be fixed in followups.
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
COPYING was changed
[https://github.com/strukturag/libheif/commit/377a957bd84018f4d27588c989fa5c66935c16ed]
1.19.8
Set essential flag for transformative properties as required by MIAF. This fixes the display of AVIF images with transformations encoded by libheif in Chrome, which checks whether this flag is set.
If the environment variable LIBHEIF_SECURITY_LIMITS is set to OFF, libheif will not check any security limits. This can be used if a user wants to work with large images that were blocked by the security limits, but the application software does not allow to adjust the libheif security limits.
Resolved processing 16-bit JPEG-2000
1.19.7
Fixes a build error with SVT-AV1 encoder plugin when using reduced symbol visibility (#1480).
1.19.6
Bugfix release.
Additionally, there are the following changes:
C++ and Go wrapper licenses have been changed to MIT
supports SVT-AV1 v3.0.0 encoder
support emscripten builds for ES6 modules
Fixes
CVE-2025-43966
CVE-2025-43967
Signed-off-by: Markus Volk <f_l_k@t-online.de>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
openh264 is an optional dependency so its good to make it a configurable
option since the build says that its an optional dependency, this helps
in building libheif for architectures like riscv32
Signed-off-by: Khem Raj <raj.khem@gmail.com>
libheif is an ISO/IEC 23008-12:2017 HEIF and AVIF (AV1 Image File Format) file format decoder and encoder. There is partial support for ISO/IEC 23008-12:2022 (2nd Edition) capabilities.
HEIF and AVIF are new image file formats employing HEVC (H.265) or AV1 image coding, respectively, for the best compression ratios currently possible.
libheif makes use of libde265 for HEIF image decoding and x265 for encoding. For AVIF, libaom, dav1d, svt-av1, or rav1e are used as codecs.
Signed-off-by: Markus Volk <f_l_k@t-online.de>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Ankur Tyagi
Leon Anavi
Gyorgy Sarvari
Alexander Kanavin
Markus Volk
Khem Raj