libheif CVE-2026-84384

Exploitation requires the target to decode an attacker-supplied HEIF or AVIF file containing crafted compressed mime metadata or unci image data with a compressed cmpC/icef structure (brotli, or zlib/deflate) using libheif 1.19.0-1.23.1. The brotli decompression path has no output bound at all; the zlib path only checks a small temporary buffer in a branch valid streams never reach; and icef units are not required to be disjoint, so a tiny box can point multiple units at the same slice for repeated decompression amplification. Limiting factors: impact is availability-only (crash/OOM, no code execution or data disclosure); against interactive desktop apps a user must open the file (effective UI:R), while UI:N genuinely applies only to automated server-side image pipelines that ingest untrusted files. The fix (heif_security_limits) is enforced only when a security-limits object is present, so callers passing raw extents with no limits remain unbounded.

This is a genuine but bounded-priority denial-of-service issue. The vendor CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5) reflects a pure availability impact with no confidentiality or integrity loss - CWE-409 (data amplification / decompression bomb), consistent with the description of unbounded brotli/zlib output growth and re-decompression of overlapping icef units. No EPSS score, no CISA KEV listing, and no public exploit are present in the provided intelligence: no public exploit identified at time of analysis. The advisory ships a fix (v1.23.2) rather than a weaponized PoC, so the real-world signal is 'defect confirmed by vendor, no active exploitation evidence.' One tension to verify: CVSS marks UI:N (no user interaction), which is accurate for automated server-side pipelines that ingest untrusted HEIF/AVIF, but on desktop consumers the file must be opened by a user (effectively UI:R); the realistic vector depends on deployment. Also note the input Tag 'Information Disclosure' conflicts with the vendor vector (C:N) - this is a DoS, not an info-leak, and should not be triaged as data exposure.

An attacker sends or uploads a small crafted HEIF/AVIF file to a service that decodes untrusted images (thumbnailer, image-conversion API, chat/photo pipeline) using libheif 1.19.0-1.23.1. During file opening, HeifContext::interpret_heif_file_images() decompresses the mime/unci compressed metadata items with no output size bound, and overlapping icef units re-decompress the same payload repeatedly, ballooning memory until the process is OOM-killed. No public exploit is identified, but the technique is a straightforward decompression bomb requiring no authentication or special privileges against exposed pipelines.