libheif CVE-2026-84383

Requires the target to decode an attacker-crafted HEIF/HEIC file whose structure uses nested iden/auxl items to reference DUPLICATE Alpha planes for the same channel - this is the specific trigger that makes transfer_channel_from_image_as() append a second, invisible Alpha plane later over-written by scale_nearest_neighbor(). Reachable in any application or service that decodes untrusted HEIF input via libheif < 1.23.2. Limiting factors: the CVSS UI:N holds only for automated/server-side decode pipelines (e.g., image upload/thumbnail services); interactive viewers effectively require the victim to open the file (UI:R). Fixed in libheif v1.23.2, so exposure is bounded to unpatched versions.

Signals are strong but not fully aligned. The vendor CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H = 9.8) treats this as remote, unauthenticated, no-interaction full-impact code execution. That UI:N is only realistic for automated server-side image pipelines (upload thumbnailers, indexers, gallery/CDN transcoders) where libheif decodes attacker-supplied HEIF files with no human in the loop; for the common case of a user opening an image in a viewer, this is effectively UI:R, which would drop the honest score to ~8.8. The root cause is a genuine CWE-787 heap out-of-bounds WRITE (confirmed by the commit diff: a duplicate Alpha plane is silently appended, becomes invisible to find_storage_for_channel()/size queries, but is still walked and written by scale_nearest_neighbor()), so C:H/I:H/A:H is a plausible ceiling - though memory-corruption bugs of this shape are realistically a crash/DoS first and reliable RCE second. No EPSS score, no CISA KEV entry, and no public weaponized exploit are present in the provided data - so this is 'no public exploit identified at time of analysis,' NOT active exploitation, despite the 9.8. A regression unit test (tests/duplicate_alpha_channel.cc) ships with the fix and demonstrates the triggering condition, which lowers the bar for researchers to reproduce it but is not an in-the-wild exploit. Net: treat as a real, high-priority patch item because libheif is broadly embedded and the bug is remotely reachable via file input, but do not over-weight the 9.8 - the no-interaction assumption and the write-primitive-to-RCE gap are the key uncertainties.

An attacker crafts a malicious HEIF/HEIC file whose nested iden/auxl item structure references duplicate Alpha planes, then delivers it to a target that decodes it with libheif < 1.23.2 (e.g., uploads it to a web service that auto-generates thumbnails, or gets a victim to open it in a HEIF-enabled viewer). During decode, transfer_channel_from_image_as() attaches a second, mis-sized Alpha plane that scale_nearest_neighbor() then writes past, corrupting the heap. No public exploit code was identified, but the fix ships with a regression test that reproduces the duplicate-plane condition.