CVE-2026-84448 in libheif
Summary
by MITRE • 09/18/2026
libheif is a HEIF and AVIF file format decoder and encoder. Prior to 1.23.2, the public heif_region_item_add_region_inline_mask_data() function in libheif/api/libheif/heif_regions.cc accepts mask_data_len without verifying that it equals the byte count required by width and height. A later heif_region_get_mask_image() call derives the read length from the region geometry, so an undersized stored buffer causes heif_region_get_inline_mask_image() to read beyond the heap allocation and copy adjacent bytes into the returned monochrome mask image. This can disclose heap data or crash an application that constructs region metadata through the writer API, while the file-parsing path is not affected because it validates the canonical mask size. This issue is fixed in version 1.23.2.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified within libheif versions prior to 1.23.2 represents a critical heap-based out-of-bounds read flaw located specifically within the region metadata handling subsystem of the library. Libheif serves as a widely adopted open-source implementation for decoding and encoding High Efficiency Image File Format (HEIF) and AV1 Image File Format (AVIF) containers, which are increasingly prevalent in modern mobile photography and web graphics due to their superior compression efficiency compared to legacy formats like JPEG or PNG. The specific defect resides in the public application programming interface function heif_region_item_add_region_inline_mask_data(), which is designed to allow developers to programmatically construct region metadata by supplying inline mask data along with its length parameter, known as mask_data_len. In vulnerable versions of the library, this function fails to perform a critical validation check that ensures the provided mask_data_len corresponds exactly to the byte count required by the specified width and height dimensions of the image region. This lack of input verification creates a discrepancy between the logical size expected for proper rendering and the actual amount of memory allocated or referenced during subsequent operations.
The operational impact of this flaw manifests when an application utilizes the writer API to construct HEIF files containing regions with inline masks. Because the library does not validate that the supplied length matches the geometric requirements, it may accept a mask_data_len value that is smaller than what is necessary for the given width and height dimensions. When a subsequent call is made to heif_region_get_mask_image(), which retrieves the image data associated with the region, the function derives the read length from the actual region geometry rather than the originally provided buffer size. Consequently, this mismatch causes the internal routine heif_region_get_inline_mask_image() to attempt reading memory beyond the bounds of the heap allocation that was made for the mask data. This out-of-bounds access results in adjacent bytes being copied into the returned monochrome mask image structure, leading to a classic heap-based buffer over-read condition.
From a security perspective, this vulnerability poses significant risks including information disclosure and potential denial of service conditions. The leakage of adjacent heap memory can expose sensitive application data such as cryptographic keys, session tokens, or other private user information stored in nearby memory locations, thereby compromising the confidentiality of the host application. Furthermore, if the out-of-bounds read accesses unmapped memory pages or triggers a segmentation fault during the copying process, it can cause the application to crash abruptly, resulting in a denial of service for users relying on services that utilize libheif for image processing. It is important to note that this specific vulnerability path is limited to applications using the writer API to build region metadata programmatically; the standard file-parsing path remains unaffected because the decoder logic correctly validates the canonical mask size against the geometric dimensions before proceeding with data extraction, thereby preventing similar exploitation through maliciously crafted input files.
This issue aligns with Common Weakness Enumeration (CWE) category CWE-125, which describes Out-of-bounds Read vulnerabilities where software reads past the end of a buffer or array. In terms of attack vector classification under the MITRE ATT&CK framework, this vulnerability facilitates data exfiltration techniques often associated with memory scraping or information leakage from process memory spaces. The exploitation typically requires local access to trigger if an attacker can influence the parameters passed to the writer API within a trusted application context, making it relevant for scenarios involving untrusted input in desktop applications or server-side image processing pipelines that accept user-defined region configurations.
To mitigate this risk, organizations and developers utilizing libheif must ensure they upgrade to version 1.23.2 or later where the validation logic has been corrected to enforce strict equality between the provided mask data length and the required byte count derived from width and height dimensions. For applications that cannot immediately update their dependencies, implementing additional input validation layers at the application level is recommended. Developers should verify that any region metadata constructed programmatically adheres strictly to geometric constraints before passing it to libheif functions. Additionally, employing memory safety tools such as AddressSanitizer during development and testing phases can help detect similar boundary violations in custom code paths interacting with image processing libraries. Maintaining up-to-date dependencies is the most effective defense against these types of low-level memory corruption vulnerabilities that stem from insufficient input validation in core library components.