CVE-2026-84447

What it actually does

Crafted HEIF/AVIF files can force libheif 1.23.1 and earlier to repeatedly decode the same base image via grid, overlay (iovl), and identity (iden) item reference graphs. processed_ids is copied per branch instead of shared, and ImageItem::decode_image() has no shared operation budget, so decode work can grow without bound and exhaust CPU (and potentially memory) in the decoding process. Confidentiality and integrity are not affected; impact is availability of the decoder and any service that invokes it.

Why it matters to the business

Unauthenticated image ingest—uploads, thumbnails, transcoding, previews, CDNs, and photo apps that use libheif—can be stalled or taken down by a single malicious file, interrupting user-facing media workflows and tying up worker capacity. There is no reported in-the-wild use, it is not on CISA KEV, exploit maturity is none, and it is 16 days since publication, so urgency comes from exposed decode paths rather than active campaigns. Downstream products that vendor or statically link libheif inherit the outage risk until they ship 1.23.2.

How an attack unfolds

An unauthenticated attacker delivers a HEIF or AVIF whose item graph uses grid, iovl, and iden references so the same underlying image is decoded many times. Any network-reachable or user-driven path that parses the file with libheif 1.23.1 or earlier (upload, email, preview, transcode) is sufficient; no privileges or extra interaction are required. The decoder follows each branch independently without a shared processed-ID set or global decode budget, amplifying work until the worker hangs, times out, or the host CPU is saturated. No named threat actors, ransomware families, or KEV-listed campaigns are associated with this CVE.

How to fix it

Upgrade libheif to 1.23.2 or later and rebuild/redeploy every binary, container, OS package, and language binding that links it, including statically linked image pipelines. If upgrade cannot be immediate: stop accepting HEIF/AVIF at the edge, isolate decode in sandboxed workers with strict CPU, memory, and wall-clock limits, and do not decode untrusted images in shared or privileged processes. Prefer upgrading over long-term format blocking so legitimate grid/overlay images keep working.

How to confirm the fix worked

Confirm runtime libheif is 1.23.2 or newer via package version, shared-library inspection, or the application’s linked-library inventory; include statically linked copies. After upgrade, decode a corpus of legitimate HEIF/AVIF files (including grid and overlay images) to verify functionality, and confirm decode of untrusted or pathological derived-image graphs completes or fails within configured time and memory limits. Watch decode latency, worker timeouts, and CPU after rollout.

Typical attack path

1. Find a service or application that decodes untrusted HEIF/AVIF with libheif 1.23.1 or earlier
2. Submit a crafted HEIF/AVIF whose grid, iovl, or iden item graph causes repeated decode of the same base image
3. Trigger parse, thumbnail, or transcode so libheif runs ImageItem::decode_image on the file
4. Allow unbounded per-branch decode work to saturate CPU or hang the worker
5. Repeat submissions to keep media-processing capacity exhausted

How to detect it

This is resource-exhaustion DoS, not a malware implant, and there is no public exploitation or named actor activity. Hunt for CPU spikes, worker hangs, request timeouts, 5xx on thumbnail/transcode endpoints, and OOM kills in processes that link libheif around handling of .heic/.heif/.avif uploads. Hang or crash stacks pointing at ImageItem::decode_image or grid/iovl/iden handling in libheif are relevant artifacts; preserve suspect images and decode them only in an isolated, resource-capped environment. Correlate bursts of image uploads with subsequent decode-worker unavailability. Absence of distinctive implant IOCs does not rule out abuse of the decode path.

What your security team should do

• Patch to libheif 1.23.2 everywhere it is packaged, vendored, or statically linked—this is the primary fix
• Inventory all HEIF/AVIF ingest and transcode paths and record the linked libheif version
• Until patched, sandbox decoders with CPU/time/memory limits and consider temporarily rejecting HEIF/AVIF at the gateway
• Add dependency and image-pipeline regression checks so libheif cannot regress below 1.23.2
• Treat as operationally important despite not being KEV: unauthenticated DoS against media workers is enough to disrupt customer journeys