CVE-2026-84444

What it actually does

When libheif is built with WITH_UNCOMPRESSED_CODEC, heif_context_add_image_tile() accepts an independently constructed tile whose component-plane dimensions do not match the prototype image's tile geometry. ImageItem_uncompressed::add_image_tile() forwards that tile to unc_encoder::encode_tile() without check_component_sizes(). The encoder sizes its heap output from the configured tile geometry but copies the tile's actual plane dimensions, so an oversized plane causes unc_encoder_component_interleave::encode_tile() to write attacker-controlled data past the heap output buffer. Result is heap memory corruption with high integrity and availability impact (process crash or corrupted encoded output) and no confidentiality impact.

Why it matters to the business

Any product that encodes HEIF or AVIF with libheif's uncompressed codec can be crashed or have encoded output silently corrupted, interrupting media pipelines, UGC processing, and imaging features. The flaw is about 16 days old, is not on CISA KEV, is not associated with ransomware, and has no known exploit maturity, so mass exploitation is not indicated; unpatched encoders still pose an integrity and availability risk until upgraded to 1.23.2.

How an attack unfolds

An attacker targets a network-reachable encoder or API that uses libheif built with uncompressed-codec support and can add image tiles without authenticating. They supply a tile whose component planes are larger than the prototype tile geometry. Because add_image_tile() skips the size gate, encode_tile() allocates from the smaller configured geometry and memcpy-style copies the oversized planes, overflowing the heap buffer. High attack complexity applies: the build flag must be on and the tile must be constructed independently of the prototype. No privileges or user interaction are required. Success yields a crash (denial of service) or corrupted in-process state and encoded bytes rather than information disclosure. No named threat actors or KEV/ransomware use are reported.

How to fix it

Upgrade libheif to 1.23.2 or later on every build and distribution that ships the library. Rebuild and redeploy all applications, containers, and native packages that statically or dynamically link libheif. If uncompressed HEIF encoding is not required, rebuild without WITH_UNCOMPRESSED_CODEC to remove the vulnerable path. Inventory transcoders, media workers, and mobile/desktop apps that vendor libheif and pin them to the fixed release. There is no complete configuration workaround while remaining on a pre-1.23.2 build with the uncompressed codec enabled.

How to confirm the fix worked

Confirm the running libheif is 1.23.2 or newer (package version, shared-object SONAME/metadata, or heif_get_version()). For source builds, verify WITH_UNCOMPRESSED_CODEC is off unless needed, and that ImageItem_uncompressed::add_image_tile() / unc_encoder::encode_tile() include check_component_sizes() (or equivalent) before copying planes. Regression-test encoding of uncompressed tiles whose component-plane sizes do not match prototype geometry and confirm rejection rather than overflow or crash. Scan images, lockfiles, and SBOM/CPE data for libheif < 1.23.2.

Typical attack path

1. Locate a reachable HEIF/AVIF encoding path that uses libheif compiled with WITH_UNCOMPRESSED_CODEC.
2. Cause the application to create a prototype image (tile geometry) and then add a separately constructed uncompressed tile.
3. Make that tile's component-plane dimensions larger than the prototype tile geometry.
4. Invoke heif_context_add_image_tile() so ImageItem_uncompressed::add_image_tile() calls unc_encoder::encode_tile() without check_component_sizes().
5. Heap overflow in unc_encoder_component_interleave::encode_tile() corrupts adjacent heap, crashing the process or corrupting encoded output.

How to detect it

This overflow happens in-process during encode, so look for crashes and heap corruption rather than a network signature. Collect coredumps and crash reports from HEIF/AVIF encoding workers and search stack traces for heif_context_add_image_tile, ImageItem_uncompressed::add_image_tile, unc_encoder::encode_tile, or unc_encoder_component_interleave::encode_tile. Correlate abrupt encoder-process deaths, allocator abort logs (e.g. malloc/free assertion, AddressSanitizer heap-buffer-overflow), and failed or truncated HEIF/AVIF outputs around the same time. Review whether the crashed binary linked libheif older than 1.23.2 with uncompressed codec enabled. No public exploit, KEV listing, or named actor activity is documented, so treat hits as suspicious crashes to triage, not confirmed compromise.

• heif_context_add_image_tile
• ImageItem_uncompressed::add_image_tile
• unc_encoder::encode_tile
• unc_encoder_component_interleave::encode_tile
• libheif.so
• WITH_UNCOMPRESSED_CODEC

What your security team should do

• Patch or rebuild to libheif 1.23.2 immediately on all encoding paths; treat static links and container base images as in-scope.
• Inventory where WITH_UNCOMPRESSED_CODEC is enabled and disable it if uncompressed encoding is unused.
• Prioritize internet-facing or unauthenticated media-encoding APIs given AV:N, PR:N, UI:N.
• Add SBOM/dependency tracking for libheif so future decoder/encoder CVEs are visible.
• Watch for worker crashes and heap-corruption telemetry in image-encoding processes; known exploit maturity is none and KEV is false, so hunting is precautionary rather than incident-driven.