libheif CVE-2026-62291

Exploitation requires the target application to execute a complete decode-then-re-encode workflow on attacker-supplied input using the uncompressed (heif_compression_uncompressed) encoder path - applications that only decode for display without re-encoding are not vulnerable via this specific code path. The crafted file must be an image sequence (not a still image) with a primary track and an auxiliary alpha track of differing dimensions. User interaction is required per CVSS (UI:R): a user must open the file or an automated system must ingest it into a pipeline. No elevated privileges are required (PR:N per CVSS). Limiting factors: decode-only viewers are unaffected; applications using non-uncompressed codecs (HEVC, AV1) for re-encoding do not trigger the vulnerable encoder path; ASLR and heap hardening on modern platforms complicate escalation from OOB write to reliable RCE.

CVSS 5.3 Medium with vector AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L correctly identifies this as a file-processing flaw that requires user or application action to trigger. The local attack vector and required user interaction meaningfully bound exposure: opportunistic network-scale attacks are not possible, and exploitation requires the crafted file to reach a decode-then-re-encode pipeline. However, the impact ratings of L/L/L may understate real-world severity - attacker-controlled heap corruption has historically been leveraged to achieve arbitrary code execution, which would elevate the effective impact to C:H/I:H/A:H on vulnerable processes. The conservative CVSS scoring likely reflects the absence of a confirmed RCE path rather than the inherent primitives the bug provides. No EPSS data was included in the intelligence; no KEV listing exists; no standalone public exploit has been observed beyond the regression test shipped with the patch. Real-world priority should be higher for applications performing automated, server-side decode/re-encode on untrusted HEIF/AVIF inputs (thumbnail generators, transcoders, batch media processors) than for interactive image viewers where UI:R naturally limits the attack surface.

An attacker crafts a HEIF image sequence file containing a 2x2 luma primary track and a 256x256 auxiliary alpha track, then delivers it to a media processing pipeline - via email attachment, a web form accepting image uploads, or injection into a batch transcoding job. When the application decodes and re-encodes the file using libheif's uncompressed encoder (a common thumbnail generation or format conversion workflow), the encoder copies 65,536 alpha samples into a 4-sample heap allocation, overwriting adjacent heap metadata and potentially enabling code execution depending on heap layout and available exploit mitigations.