libheif CVE-2026-84447

Exploitation requires that the target decode an attacker-supplied HEIF/AVIF file through libheif 1.23.1 or earlier using the derived-image code paths - specifically grid (grid), iovl (image overlay), or iden (identity) reference items that form a shared/nested reference graph over a common base image. The vulnerable behavior is inherent to the decoder's default derived-image handling; no non-default configuration or feature toggle is needed. Limiting factors: an attacker must be able to submit a file that the victim actually decodes - trivial for automated upload/thumbnail/transcode services (matching AV:N/UI:N), but for desktop applications a user must open the crafted file (effectively user interaction). Impact is availability-only (CPU/memory exhaustion); no code execution, data disclosure, or data modification results. Fixed builds (>=1.23.2) enforce a shared decode budget derived from security_limits->max_items, so the DoS does not trigger there.

This is a genuine but bounded denial-of-service issue. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, base 7.5) reflects pure availability impact with no confidentiality or integrity effect - CWE-770 (uncontrolled resource consumption). The high score is driven entirely by A:H combined with network reach and no privilege/interaction requirement, which is appropriate for automated server-side image pipelines that decode uploaded HEIF/AVIF files without human involvement. There is NO EPSS score, NO CISA KEV listing, and NO public exploit (POC) in the provided intelligence, so real-world exploitation pressure is currently low. The commit diff strongly corroborates the mechanism (introduction of a shared atomic decode budget and a finished_items DFS memo), meaning the vulnerability is well-understood and confirmed by source evidence rather than speculative. Net: this is a legitimate patch-worthy DoS for anyone processing untrusted images at scale, but it is not an urgent actively-exploited priority - treat as routine dependency hygiene unless you run a high-volume image-ingest service. Note a signal nuance: vendor sets UI:N, which is correct for automated pipelines but overstates exposure for desktop viewers where a user must open the crafted file (effectively UI:R).

An attacker uploads a small crafted HEIF/AVIF file containing grid, iovl, or iden reference graphs that point repeatedly at a shared base image; because processed_ids is copied per recursion branch and there is no shared decode budget, an image-processing service (thumbnailer, CDN transcoder, upload pipeline) re-decodes the same base image an exponential number of times, and the ref-cycle DFS also explores every distinct path. This exhausts CPU (and memory), stalling or crashing the worker from a tiny input with high amplification. No public exploit code is identified at time of analysis.