CVE-2026-84384

What it actually does

A crafted HEIF or AVIF file can drive libheif's brotli and zlib decompression of mime metadata and unci image data to accumulate output with no effective size cap or MemoryHandle accounting. HeifContext::interpret_heif_file_images() processes multiple compressed metadata items at open time, so a small file can allocate unbounded memory and terminate the decoding process. Confidentiality and integrity are not affected; impact is availability-only (process crash or host memory exhaustion). Affected releases are libheif 1.19.0 through 1.23.1.

Why it matters to the business

Any product that opens untrusted HEIF/AVIF images with libheif—media pipelines, thumbnails, upload processors, browsers, mobile galleries, CDNs, and DAM systems—can be crashed or OOM-killed by a single small file, causing service interruption, dropped jobs, and worker restarts. There is no CISA KEV listing, no ransomware association, and exploit maturity is none at 16 days after publication (2026-09-18), so mass exploitation is not evidenced; treat as a high-availability patch for internet-facing decoders rather than an emergency KEV event.

How an attack unfolds

An unauthenticated attacker supplies a small HEIF or AVIF file whose mime metadata and unci image data are structured so that decompress_brotli() and/or do_inflate() expand without a bound, including via overlapping icef units that inflate the same payload repeatedly. When any application using a vulnerable libheif opens the file, interpret_heif_file_images() decompresses those items during parse, memory grows without limit, and the process is terminated. Delivery is ordinary file intake (upload, attachment, URL fetch, shared album)—no credentials or user interaction beyond the service accepting the file. No named threat actors or campaigns are associated.

How to fix it

Upgrade libheif to 1.23.2 or later, which bounds decompression output and accounts memory correctly. Rebuild and redeploy every binary, container, and language binding that statically or dynamically links libheif (including downstream image toolkits and OS packages). Until upgrade is complete, reject or sandbox untrusted HEIF/AVIF at the edge, disable HEIF/AVIF decode on internet-facing workers, and apply OS-level memory/cgroup limits so a single decoder cannot take down the host. Do not rely on file-size limits alone; the issue is expansion of a small input.

How to confirm the fix worked

Inventory installed libheif versions (package manager, linked soname, or build manifests) and confirm runtime is 1.23.2 or newer on every decoder host. After upgrade, open a corpus of legitimate HEIF/AVIF files through the same code path and verify decode succeeds without abnormal RSS growth. Confirm edge controls still reject unexpected image types if you temporarily disabled HEIF/AVIF. Do not use weaponized samples to prove the old bug.

Typical attack path

1. Obtain or generate a small HEIF/AVIF file that triggers unbounded brotli/zlib metadata expansion in libheif 1.19.0–1.23.1.
2. Deliver the file to a service or client that decodes HEIF/AVIF with the vulnerable library (upload, email, messaging, web fetch, or shared media).
3. Wait for the decoder to open the file and run HeifContext::interpret_heif_file_images().
4. Observe process crash, worker death, or host OOM as memory grows without bound.
5. Repeat against remaining workers or instances to sustain an availability outage.

How to detect it

This is a memory-exhaustion crash, not a persistence or implant issue; look for sudden RSS growth and termination of processes that decode HEIF/AVIF, clustered around file-open of .heic/.heif/.avif. Review application logs, container OOM killer events (dmesg/journal), crash reporters, and worker orchestrators for abort/segfault/OOM of libheif-linked binaries shortly after image intake. Stack traces naming decompress_brotli, do_inflate, or HeifContext::interpret_heif_file_images during file open are consistent with this bug. Preserve the triggering object from upload stores if a crash is found. No named APT activity is documented; absence of these artifacts does not prove the library was never hit, only that a crash was not recorded.

• HeifContext::interpret_heif_file_images
• decompress_brotli
• do_inflate
• libheif
• killed process .* (oom|Out of memory)
• Content-Type: image/heic
• Content-Type: image/heif
• Content-Type: image/avif
• .heic
• .heif
• .avif

What your security team should do

• Patch libheif to 1.23.2+ and redeploy all image-decode services, prioritizing internet-facing upload and thumbnail workers.
• Inventory static and dynamic dependents of libheif across containers, OS packages, and vendor appliances.
• Until patched, isolate HEIF/AVIF decode behind memory-capped sandboxes or disable the format at the perimeter.
• Watch for decoder crashes and OOM kills on media workers; exploit maturity is none and the CVE is not in KEV, but availability impact is high (CVSS 7.5).
• Track vendor and distro advisories for downstream products that embed libheif rather than assuming a single library upgrade covers the fleet.