Description

libheif is a HEIF and AVIF file format decoder and encoder. In 1.23.0 and earlier, a crafted image sequence with a 2x2 primary plane and a 256x256 auxiliary alpha plane can cause attacker-controlled heap corruption during a normal decode and re-encode workflow. Track_Visual::decode_next_image_sample() calls transfer_channel_from_image_as() without checking that the auxiliary alpha dimensions match the main frame. The resulting inconsistent image reaches heif_track_decode_next_image() and then heif_context_encode_image(). In unc_encoder::encode(), unc_encoder_component_interleave::encode_tile() sizes its buffer with compute_tile_data_size_bytes() using the primary dimensions but copies each component using its actual plane dimensions. The oversized alpha plane is therefore copied beyond the allocation, causing an out-of-bounds write; the inverse size mismatch can also produce an out-of-bounds read. This issue is fixed in version 1.23.1.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-08-18T22:17:02.877Z",
  "pubdate": "2026-08-18T22:17:02.877Z",
  "executiveSummary": "An out-of-bounds write and read vulnerability exists in libheif versions 1.23.0 and earlier, specifically within the image decoding and re-encoding workflow. The flaw is triggered when processing a crafted image sequence containing mismatched dimensions between the primary plane and the auxiliary alpha plane, such as a 2x2 primary plane paired with a 256x256 auxiliary alpha plane. This dimension mismatch leads to attacker-controlled heap corruption during standard decoding and re-encoding operations.\nThe primary risk associated with this vulnerability is memory corruption, which can lead to application crashes or potentially arbitrary code execution depending on the execution context and memory layout. An attacker capable of supplying a maliciously crafted HEIF or AVIF file can exploit this vulnerability without authentication, provided the target application processes the malicious file through the vulnerable decode and re-encode workflow.",
  "technicalDetails": "The root cause of the vulnerability is an inadequate dimension validation check within the Track_Visual::decode_next_image_sample() function. Specifically, the function invokes transfer_channel_from_image_as() without verifying that the auxiliary alpha plane dimensions match the dimensions of the main frame. Consequently, an inconsistent image structure is produced and propagated through the decoding pipeline, eventually reaching heif_track_decode_next_image() and heif_context_encode_image().\nDuring the encoding phase within unc_encoder::encode(), the unc_encoder_component_interleave::encode_tile() function calculates buffer sizes using compute_tile_data_size_bytes() based strictly on the primary image dimensions. However, when copying the individual components, it utilizes the actual plane dimensions rather than the primary dimensions. When processing an oversized auxiliary alpha plane, the component data is copied beyond the boundaries of the allocated buffer, resulting in a heap-based out-of-bounds write. Conversely, an inverse size mismatch can trigger an out-of-bounds read operation.\nThe attack flow proceeds as follows: First, an attacker crafts a malicious HEIF or AVIF image file featuring mismatched primary and auxiliary alpha plane dimensions. Second, the victim application ingests the file and initiates a decode and re-encode workflow. Third, Track_Visual::decode_next_image_sample() processes the sample without validating plane dimensions, passing the malformed image downstream. Fourth, unc_encoder_component_interleave::encode_tile() allocates a buffer too small for the auxiliary plane due to relying on primary dimensions. Finally, the oversize plane copy operation overflows the heap buffer, leading to memory corruption and potential code execution."
}