libheif CVE-2026-49271

The vulnerable code path is reached only when processing HEIF files that use the uncompressed codec path with icef (item content extent fragment) box data present - not all HEIF files trigger this decoder. Exploitation requires that the target application invoke libheif's uncompressed HEIF decoder on an attacker-supplied file, which happens either through direct user action (opening a file) or an automated pipeline that ingests HEIF/AVIF content. No authentication or special privilege is required from the attacker's perspective; the only prerequisite is file delivery to a vulnerable consumer. Exploitation is limited by: (1) mandatory file-open interaction or pipeline trigger (UI:R in isolated desktop contexts); (2) scope restricted to the process running libheif - no lateral movement is implied by the crash; (3) the vulnerability does not affect AVIF files processed through other decoder paths, only HEIF files exercising the uncompressed icef path. Applications that only process AVIF or HEIF files via non-uncompressed codec paths are not exposed through this specific vector.

The CVSS 3.1 base score of 6.5 (AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H) accurately characterises this as a network-reachable, unauthenticated denial-of-service requiring only that a victim open a crafted file - a common, low-friction precondition in consumer and server image-processing contexts. Attack complexity is low once a malformed file is constructed. The mandatory user interaction (UI:R) or automated pipeline trigger moderates urgency compared to a fully autonomous server-side flaw. No EPSS score was supplied; given no KEV listing and no confirmed public POC, real-world exploitation probability is presently low but non-negligible given that libheif is embedded in many downstream applications (GNOME, FFmpeg pipelines, Apple ecosystem wrappers) that routinely ingest untrusted images. The 'Information Disclosure' tag and CWE-125 classification introduce a theoretical secondary risk - heap contents adjacent to the buffer could be transiently readable - but because the crash terminates the process, reliable data extraction is unlikely without a more controlled exploitation primitive. Overall this is a genuine patch-priority item for any service that auto-processes user-supplied HEIF/AVIF files (attack surface broadens to AV:N/AC:L effectively) and a lower-urgency item for desktop applications where UI:R is a real friction factor.

An attacker hosts or emails a maliciously crafted HEIF image file containing icef box fields engineered to trigger the unit_offset + unit_size integer wrap. When a victim opens the file in any application linked against libheif prior to 1.22.1 - such as an image viewer, a photo management app, or a web service that auto-generates thumbnails - the uncompressed decoder bypasses the range check, constructs an iterator outside the heap buffer, and the application crashes. In automated server-side pipelines (e.g., image transcoding APIs), no user interaction beyond file upload is required, effectively reducing the UI:R constraint to near-zero friction. No confirmed public POC exists at time of analysis.