CVE-2026-84450 in libheif
Summary
by MITRE • 09/18/2026
libheif is a HEIF and AVIF file format decoder and encoder. From 1.19.0 until 1.23.3, a crafted image item containing a clap property and an ispe width or height greater than INT32_MAX + 1 can reach crop calculations through heif_image_handle_get_image_tiling(). Box_clap::left_rounded() or Box_clap::top_rounded() passes the image dimension minus one to Fraction::Fraction(), whose uint32_t constructor uses an assertion as input validation, causing assert-enabled builds to abort. Release builds can instead compute invalid crop geometry, and the tiling API returns dimensions that the normal decode security limits reject. This issue is fixed in version 1.23.3.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified within libheif versions ranging from 1.19.0 to 1.23.3 represents a critical integer overflow and validation bypass flaw located in the handling of HEIF image items, specifically concerning the clap property which defines cropping parameters for an image region. The core technical failure occurs when a crafted input file specifies an ispe width or height value that exceeds INT32_MAX plus one. This excessive dimension triggers downstream calculations within the heif_image_handle_get_image_tiling function, where the crop geometry is computed based on these malformed inputs. Specifically, the methods Box_clap::left_rounded() and Box_clap::top_rounded() are invoked to determine the precise cropping boundaries. These methods pass a calculated value derived from the image dimension minus one directly into the Fraction class constructor.
The fundamental flaw lies in how the Fraction class handles this input during its uint32_t construction phase. In builds compiled with assertions enabled, the library performs strict validation that detects the invalid state resulting from the oversized dimensions, leading to an immediate abort of the process via assertion failure. This behavior effectively causes a denial of service for applications utilizing assert-enabled debug or testing builds of libheif. However, in release builds where assertions are typically disabled to optimize performance and reduce binary size, this validation step is bypassed entirely. Consequently, the library proceeds with invalid crop geometry calculations that do not adhere to standard integer limits or expected data ranges.
The operational impact of this vulnerability extends beyond simple process termination. In production environments running optimized release binaries, the incorrect computation allows tiling APIs to return dimensions that fall outside normal decode security limits. This discrepancy can lead to buffer overflows, memory corruption, or other undefined behaviors when subsequent decoding stages attempt to allocate buffers or access pixel data based on these erroneous dimensions. Attackers leveraging this flaw could potentially craft malicious HEIF files designed to exploit the resulting instability in host applications such as image viewers, web browsers, or content management systems that rely on libheif for format parsing. The lack of robust boundary checking at the point where crop parameters are rounded and converted creates a significant attack surface for remote code execution or denial-of-service attacks depending on how the downstream consumer handles the invalid data structures returned by the tiling API.
Mitigation strategies primarily involve upgrading to version 1.23.3 or later, which addresses these validation gaps by implementing stricter checks on input dimensions before they are processed through rounding and conversion routines. For organizations unable to immediately update their dependencies, defensive programming practices should be adopted within application layers that consume libheif outputs. This includes validating the returned tiling dimensions against expected maximums before allocating memory or processing pixel data. Additionally, ensuring that development environments utilize assert-enabled builds during testing phases can help identify such integer overflows early in the software lifecycle. From a classification perspective, this vulnerability aligns with CWE-190 Integer Overflow or Wraparound and CWE-253 Incorrect Check of Function Return Value, as it involves improper handling of numeric limits leading to invalid state execution. In terms of adversary tactics, exploitation attempts would likely fall under ATT&CK technique T1496 Resource Hijacking if used for denial of service, or potentially T1059 Command and Control if the resulting memory corruption is leveraged for further payload delivery in a broader exploit chain.