CVE-2026-84447 in libheif
Summary
by MITRE • 09/18/2026
libheif is a HEIF and AVIF file format decoder and encoder. In 1.23.1 and earlier, crafted grid, iovl, and iden reference graphs can repeatedly decode the same base image because processed_ids is copied per branch and ImageItem::decode_image() has no shared operation budget. This vulnerability is fixed in 1.23.2.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/18/2026
The libheif library serves as a critical component for processing High Efficiency Image File Format (HEIF) and AV1 Image File Format (AVIF) files, which are increasingly prevalent in modern digital imaging ecosystems due to their superior compression efficiency compared to traditional formats like JPEG or PNG. A significant security flaw was identified within versions 1.23.1 and earlier of this library, specifically concerning the handling of complex reference graphs embedded within these image structures. The vulnerability arises from how the decoder manages computational resources when processing specific metadata elements known as grid, iovl, and iden references. These elements define relationships between different images or tiles within a single file, allowing for features like layered imagery or spatial tiling. When an attacker crafts a malicious HEIF or AVIF file containing specially constructed reference graphs, the decoder fails to enforce a global limit on decoding operations across all branches of the image structure.
The technical root cause lies in the internal logic governing how processed images are tracked and budgeted during the decoding process. Specifically, the library copies the list of processed identifiers per branch rather than maintaining a shared operational budget for the entire file. Furthermore, the ImageItem::decode_image function lacks any mechanism to track or limit the cumulative computational effort expended across all decoded items. This architectural oversight means that if an image contains deeply nested or circular reference structures, the decoder will repeatedly decode the same base image multiple times as it traverses different branches of the graph. Each branch treats its decoding tasks in isolation, unaware of the work already performed by sibling branches, leading to a redundant and exponential increase in processing demands.
This flaw results in a severe denial-of-service condition characterized by excessive CPU consumption and potential application hang or crash. Because there is no shared operation budget, an attacker can construct files that trigger infinite loops or extremely high iteration counts during the decoding phase. The repeated decoding of identical base images consumes significant computational resources without producing new output, effectively exhausting system capacity. This aligns with Common Weakness Enumeration (CWE) category CWE-400, which covers Uncontrolled Resource Consumption, and specifically relates to resource exhaustion through redundant processing. In terms of the MITRE ATT&CK framework, this vulnerability facilitates availability impact by allowing an adversary to degrade or disrupt services that rely on image parsing capabilities, such as web servers, mobile applications, or digital asset management systems.
The operational impact extends beyond simple performance degradation. Applications integrating libheif may become unresponsive when processing maliciously crafted files, leading to service outages for end-users. In server-side environments, this can be exploited in a distributed denial-of-service attack if the application automatically processes uploaded images without prior validation or resource limits. The lack of shared state management between decoding branches means that even moderately complex but carefully structured image files can cause disproportionate system load compared to their file size, making them efficient vectors for abuse.
To mitigate this vulnerability, organizations and developers must immediately upgrade libheif to version 1.23.2 or later, where the issue has been resolved by implementing proper shared operation budgets and ensuring that processed identifiers are managed globally rather than per branch. For systems unable to update promptly, defensive coding practices should be employed, such as imposing strict limits on image dimensions, tile counts, and decoding iterations before passing data to the library. Input validation mechanisms can also help detect anomalous reference structures or excessive nesting levels in incoming HEIF and AVIF files. Additionally, running image processing tasks within sandboxed environments with CPU quotas can limit the blast radius of such exploits, ensuring that even if a malicious file is processed, it cannot consume unlimited system resources.