CVE-2026-62291: libheif: Heap out of bounds write in libheif uncompressed encoder when writing images with mismatched auxiliary alpha dimensions
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. TrackVisual::decodenextimagesample() calls transferchannelfromimageas() without checking that the auxiliary alpha dimensions match the main frame. The resulting inconsistent image reaches heiftrackdecodenextimage() and then heifcontextencodeimage(). In uncencoder::encode(), uncencodercomponentinterleave::encodetile() sizes its buffer with computetiledatasizebytes() 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
libheifto a version that resolves this vulnerability.Fixed in 1.23.1 - Configuration
Ensure Track_Visual::decode_next_image_sample() validates that the auxiliary alpha plane dimensions match the main frame before calling transfer_channel_from_image_as(); reject or handle images where auxiliary alpha dimensions do not match the main frame.
Track_Visual::decode_next_image_sample() (libheif) auxiliary alpha dimensions validation before transfer_channel_from_image_as() = must check that auxiliary alpha dimensions match the main frame dimensions - Compensating control
Constrain processing to trusted/untrusted workflows by blocking or quarantining HEIF/AVIF inputs that contain mismatched auxiliary alpha dimensions to prevent the crafted oversized alpha plane from reaching heif_track_decode_next_image() / heif_context_encode_image().
Event History
Frequently Asked Questions
Which deployments are realistically exposed?
Systems using libheif 1.23.0 or earlier are affected when they process attacker-controlled image sequences through a decode-and-re-encode workflow. The vulnerable path involves an auxiliary alpha plane whose dimensions do not match the primary image plane.
What input and processing path are required for exploitation?
An attacker needs to provide a crafted image sequence with mismatched primary and auxiliary alpha dimensions and have it processed normally by the affected decode-and-re-encode path. The described example uses a 2x2 primary plane and a 256x256 auxiliary alpha plane.
What version resolves the vulnerability?
Upgrade libheif to version 1.23.1, which fixes the issue. The provided data does not specify an alternative mitigation for environments that cannot upgrade immediately.
How can I identify potentially affected processing?
Review whether your application accepts image sequences with auxiliary alpha planes and passes them from decoding into libheif encoding. Inputs with auxiliary alpha dimensions that differ from the corresponding main-frame dimensions indicate exposure to the vulnerable condition.