libheif CVE-2026-84449

Requires the application to use libheif's ENCODE path - specifically constructing an image via heif_image_create() and heif_image_add_plane() with extremely large RGB dimensions, then invoking heif_context_encode_image() to perform RGB-to-YCbCr conversion in libheif/color-conversion/rgb2yuv.cc. The stride must be large enough to overflow a 32-bit integer, meaning a genuinely huge image plane must be allocated first. Exploitation is LIMITED to versions prior to 1.19.6, to deployments that expose encoding of caller/attacker-influenced image dimensions, and by the impact being a process crash only (no code execution or data disclosure). Pure decode/file-parsing workflows are not affected.

This is a genuinely low-priority issue, and the signals are consistent rather than conflicting. The vendor CVSS of 3.7 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L) reflects a pure availability impact (a crash of the encoding process) with high attack complexity. There is no EPSS score, no CISA KEV listing, and no public exploit code - exploitation status is 'no public exploit identified at time of analysis.' The most important nuance is that AV:N overstates real-world exposure: the overflow is triggered on the ENCODE path via image dimensions supplied programmatically through heif_image_create()/heif_image_add_plane(), not by parsing an attacker-supplied HEIF/AVIF file. The wrapped uint32_t stride only occurs for 'extremely large RGB images,' which additionally requires allocating an enormous interleaved plane - a self-inflicted or degenerate-input condition more than a remote weaponizable bug. In short: a real but marginal robustness defect, not a security priority. No key data is missing; the source-code diff (uint32_t→size_t stride widening) directly corroborates the CWE-190 integer-overflow root cause.

An application using libheif's encoder accepts caller-controlled image dimensions and constructs a very large RGB image via heif_image_create()/heif_image_add_plane(), then calls heif_context_encode_image(). During RGB-to-YCbCr conversion the uint32_t stride overflows, producing an invalid input pointer that reads beyond the allocated plane and crashes the process. No public PoC exists, and the extreme image-size requirement plus high complexity make practical exploitation unlikely beyond a targeted denial-of-service against a service that lets untrusted users dictate encode dimensions.