CVE-2026-84451

What it actually does

An integer overflow in libheif’s uncompressed-tile decoder (unc_decoder::get_compressed_image_data_uncompressed, no-icef full-item path) lets a crafted HEIF/AVIF uncompressed tile grid wrap an addition-based range check (range_start_offset + range_size). The failed bounds test allows heif_image_handle_decode_image_tile() to invoke memcpy() with an invalid source pointer and an extremely large length. The result is a reliable process crash (availability loss) in tile-decoding callers; confidentiality and integrity are not indicated. Whole-image decode is not claimed to hit this path. This is an incomplete fix of CVE-2026-62292 in 1.19.0 through versions before 1.23.3.

Why it matters to the business

Any product that decodes individual HEIF/AVIF tiles with libheif 1.19.0–1.23.2 can be taken down by a user-supplied image: media viewers, thumbnailers, DAM/CMS ingest, photo apps, browsers or cloud transcoders that call tile APIs. Impact is service disruption and support load, not data theft or ransomware. The issue is 16 days old, not in CISA KEV, has no public exploit maturity, and scores medium (CVSS 6.5, UI required), so urgency is moderate but real for high-volume image pipelines. Upgrade to 1.23.3 to close the residual CVE-2026-62292 gap.

How an attack unfolds

An attacker hosts or sends a valid-looking HEIF or AVIF file whose uncompressed tile grid advertises a high tile index and oversized range_start_offset/range_size so the addition-based check wraps. The victim (or an automated ingest path) opens or tiles-decodes the file. libheif accepts the wrap, then memcpy() faults on a bad pointer and huge length, crashing the host process. Delivery is typically email, chat, web, or upload; user or pipeline interaction is required. No named threat actors or in-the-wild campaigns are associated. Whole-image decode is not the demonstrated trigger.

How to fix it

Upgrade libheif to 1.23.3 or later (the complete fix for this incomplete CVE-2026-62292 remediation). Rebuild and redeploy every application, container, and distro package that statically or dynamically links libheif 1.19.0 through 1.23.2. Prefer vendor packages that already ship 1.23.3. Until patched: disable or sandbox tile-level decode of untrusted HEIF/AVIF, reject uncompressed-tile grids at the gateway, and isolate image workers so a crash does not take down the parent service. Do not rely on the prior CVE-2026-62292 patch alone.

How to confirm the fix worked

Confirm the running libheif is 1.23.3+ (pkg-config, shared-library SONAME/version, or heif-info/heif-convert --version). Inventory all binaries that link libheif (ldd, otool, SBOM) including static embeds. After upgrade, regression-test tile decode (heif_image_handle_decode_image_tile) and whole-image decode on benign HEIF/AVIF, including uncompressed tiles. In staging, confirm previously crashing crafted samples no longer fault. Scan images, containers, and language bindings (e.g. libheif-backed Python/Go/Node modules) for versions < 1.23.3.

Typical attack path

1. Attacker crafts a HEIF/AVIF with an uncompressed tile grid that overflows the addition-based range check in the no-icef full-item decoder path.
2. File is delivered over the network (download, email, chat, or untrusted upload) to a user or ingest service.
3. Victim or pipeline invokes tile decode (heif_image_handle_decode_image_tile) rather than only whole-image decode.
4. Wrapped bounds check passes; memcpy runs with an invalid source and oversized length.
5. Decoder process crashes, causing denial of service until restarted; no privilege gain or data compromise is indicated.

How to detect it

This flaw causes a crash, not persistence, so hunt for decoder faults rather than malware. Review application, syslog/journald, container, and crash-reporter logs (apport, Breakpad/Crashpad, Windows Error Reporting) for processes that load libheif aborting or SIGSEGV/SIGABRT during HEIF/AVIF tile decode. Correlate with recent ingest of .heic/.heif/.avif from untrusted users. Inspect core dumps for memcpy in libheif uncompressed decoder frames (unc_decoder, get_compressed_image_data_uncompressed, heif_image_handle_decode_image_tile). WAF/proxy logs showing repeated uploads of those types followed by worker restarts are suspicious. No public exploit kit or named actor TTPs are documented; absence of crashes does not prove the library was never hit.

• libheif version strings 1.19.0 through 1.23.2 in package/SBOM/library metadata
• heif_image_handle_decode_image_tile
• unc_decoder::get_compressed_image_data_uncompressed
• libheif/codecs/uncompressed/unc_decoder.cc
• SIGSEGV or SIGABRT in process image containing libheif while handling .heic/.heif/.avif
• memcpy fault with oversized length in libheif uncompressed tile decode stack
• repeated worker restarts after ingest of uncompressed-tile HEIF/AVIF

What your security team should do

• Patch libheif to 1.23.3 everywhere it is linked, including static and containerized copies; treat leftover 1.19.0–1.23.2 as still vulnerable despite the earlier CVE-2026-62292 fix.
• Inventory thumbnailers, DAM/CMS ingest, mobile/desktop photo apps, and transcoders that call tile APIs; prioritize internet-facing and high-volume workers.
• Until patched, sandbox image workers, limit blast radius of a decoder crash, and optionally block or quarantine untrusted .heic/.heif/.avif at the edge.
• Add crash and core-dump alerting on processes that load libheif when handling HEIF/AVIF.
• Track this as medium urgency: not KEV, no known exploits, UI:R, but a reliable crash in common media stacks published 16 days ago.