CVE-2026-84450

What it actually does

In libheif 1.19.0 through 1.23.2, a HEIF/AVIF image item that pairs a clap (clean aperture) property with an ispe width or height greater than INT32_MAX + 1 can reach crop math via heif_image_handle_get_image_tiling(). Box_clap::left_rounded() or Box_clap::top_rounded() passes (dimension - 1) into Fraction’s uint32_t constructor, which treats an assertion as validation. Assert-enabled builds abort the process; release builds can compute invalid crop geometry, and the tiling API can return sizes that the library’s normal decode security limits would reject. Impact is availability only (crash or unstable tiling results); confidentiality and integrity are not affected.

Why it matters to the business

Apps and backends that decode or inspect untrusted HEIF/AVIF (viewers, CMS/DAM, messaging, galleries, transcode workers) can crash or restart when a user opens or a pipeline inspects a malicious file, causing brief outages, failed uploads, and support load. Severity is modest (CVSS 4.3, user interaction required, availability-low). The issue is not in CISA KEV, has no ransomware use, and exploit maturity is none, so urgency is moderate rather than emergency—but consumer media features and high-volume ingest farms still need a timely upgrade to 1.23.3 because a single uploaded image can take down an unpatched decoder process. The advisory is about 16 days old and a patch is available.

How an attack unfolds

An attacker supplies a HEIF or AVIF file whose image item includes a clap box and an ispe box advertising an extreme width or height. Delivery is any path that causes a vulnerable libheif consumer (1.19.0–1.23.2) to inspect tiling: email or chat attachment, web upload, shared folder, or a page that auto-loads images. When the application calls heif_image_handle_get_image_tiling() (or equivalent tiling/crop inspection), clap rounding feeds an out-of-range value into Fraction construction. Debug/assert builds abort immediately; release builds may return nonsensical tile or crop sizes. The attacker does not gain code execution or data access; the result is denial of service of the decoding process. No named threat actors or campaigns are associated, and there is no public exploit maturity.

How to fix it

Upgrade libheif to 1.23.3 or later and rebuild or redeploy every binary, container, and language binding that statically or dynamically links it (including HEIF/AVIF plugins in image toolchains). Inventory direct and transitive dependencies (system packages, vendored copies, mobile SDKs, and language wrappers) and replace any 1.19.0–1.23.2 instance. If an immediate upgrade is not possible, stop decoding or tiling-inspecting untrusted HEIF/AVIF, run decoders in a tightly sandboxed, restartable worker with tight memory/CPU limits, and reject or quarantine files that must not reach the vulnerable tiling path. There is no configuration-only fix inside the affected range.

How to confirm the fix worked

Confirm the runtime and build-time libheif is 1.23.3 or newer (package version, shared-object SONAME/path, and strings/symbols in the shipping binary). Re-run SCA/SBOM and container image scans until no 1.19.0–1.23.2 hits remain, including vendored trees. After rebuild, verify applications load the patched library (not an older copy on the loader path) and that HEIF/AVIF ingest still functions on known-good files. Do not use malicious images as a production test; version and linkage checks are sufficient to confirm exposure and fix.

Typical attack path

1. Attacker prepares a HEIF or AVIF file that combines a clap property with an oversized ispe width or height so crop/tiling inspection hits the defective rounding path.
2. File is delivered through a user-driven or automated ingest channel (attachment, upload, preview, thumbnail, or transcode).
3. A product linked to libheif 1.19.0–1.23.2 opens or inspects the image and invokes tiling/crop APIs such as heif_image_handle_get_image_tiling().
4. Assert-enabled builds abort; release builds may compute invalid crop geometry or tiling dimensions.
5. The decoder process or worker crashes or misbehaves, interrupting preview, upload, or transcode until the process is restarted; repeated delivery can keep unpatched auto-ingest services down.

How to detect it

This defect leaves crash artifacts, not a persistent implant. Hunt for unexpected process exits (SIGABRT/SIGSEGV, assertion aborts, core dumps) in services that decode or thumbnail HEIF/AVIF around the time a .heic/.heif/.avif was ingested. Inspect stack traces for libheif frames involving heif_image_handle_get_image_tiling, Box_clap left/top rounding, or Fraction construction. Correlate worker restarts, upload failures, and image-pipeline errors with those files. There is no known in-the-wild campaign, so treat hits as suspected crash-DoS attempts or accidental bad files unless volume or targeting suggests otherwise. Preserve cores, the triggering object, and decoder logs for forensics; network IOCs are not specific beyond ordinary image transfer.

• heif_image_handle_get_image_tiling
• Box_clap::left_rounded
• Box_clap::top_rounded
• libheif
• Assertion `.*' failed
• SIGABRT
• Content-Type: image/heic
• Content-Type: image/heif
• Content-Type: image/avif
• .heic
• .heif
• .avif

What your security team should do

• Prioritize inventory of libheif 1.19.0–1.23.2 across OS packages, containers, mobile apps, and vendored copies; patch or rebuild to 1.23.3+ first on internet-facing upload, preview, and transcode paths.
• Treat this as a moderate, availability-only issue: schedule the upgrade promptly but do not displace KEV or actively exploited work unless media ingest is business-critical.
• Until patched, isolate HEIF/AVIF decoding in restartable sandboxed workers and disable automatic tiling/preview of untrusted files where feasible.
• Add crash/abort monitoring on processes that link libheif so a single crafted file cannot fail silently in a tight restart loop.
• Track upstream dependents after they consume 1.23.3 so language bindings and image stacks are not left on the vulnerable range.