CVE-2026-84448

What it actually does

A heap out-of-bounds read in libheif’s writer/region API: heif_region_item_add_region_inline_mask_data() stores caller-supplied mask_data_len without checking it against the byte count implied by width and height. A later heif_region_get_mask_image()/heif_region_get_inline_mask_image() walk uses geometry-derived length, so an undersized buffer is over-read and adjacent heap bytes are copied into the returned monochrome mask. Impact is limited confidentiality leakage of nearby heap and possible process crash. The HEIF/AVIF file-parsing path is not affected because it enforces canonical mask size. Attack vector is local with high complexity (CVSS 4.0, C:L/I:N/A:L).

Why it matters to the business

Operational risk is low-to-moderate and narrowly scoped: only applications that construct region metadata through libheif’s writer API can leak in-process memory or crash; untrusted-file decode/ingest is not an attack surface. There is no CISA KEV listing, no ransomware association, exploit maturity is none, and the issue is 16 days old with a CVSS of 4.0, so emergency change windows are generally not warranted. Residual business effects are possible privacy exposure of in-memory content in media-authoring or transcoding services and availability hits if a writer-path crash takes down a long-running process. Priority should track whether any product actually calls the writer region APIs rather than treating all libheif users as equally exposed.

How an attack unfolds

An attacker who can already invoke the local libheif writer API (same host/process, typically via an application that builds HEIF/AVIF region items in code rather than by parsing a file) supplies a region width/height together with mask_data_len smaller than the required mask bitmap. The library accepts and stores that undersized buffer. When the application later requests the inline mask image, libheif computes the read length from geometry, reads past the heap allocation, and returns neighboring heap bytes inside the mask buffer—or faults if the over-read hits unmapped memory. The file decoder never takes this path, so crafting a malicious HEIF/AVIF on disk does not trigger the bug. No named threat actors, KEV activity, or public exploit code are associated with this CVE.

How to fix it

Upgrade libheif to 1.23.2 or later, which checks that mask_data_len matches the byte count required by width and height before storing inline mask data. Rebuild and redeploy every binary, container, or language binding that statically links libheif or vendors its sources. If an immediate upgrade is impossible, stop exposing the writer region APIs to untrusted callers and avoid constructing inline region masks with attacker-influenced dimensions or lengths; the file-parsing path does not need a special workaround. Inventory downstream HEIF/AVIF authoring tools, transcoders, and photo pipelines for libheif < 1.23.2.

How to confirm the fix worked

Confirm the linked libheif is 1.23.2+ via package manager, shared-library soname/version, or build manifests (pkg-config, ldd, otool, SBOM). Grep source and binaries for heif_region_item_add_region_inline_mask_data and heif_region_get_inline_mask_image to find writer-path users. After upgrade, regression-test region-metadata authoring: adding an inline mask and reading it back must succeed only when length matches geometry and must fail closed on a mismatched length rather than returning extra bytes or crashing. Decoder-only ingest of HEIF/AVIF files is out of scope for this CVE but can still be smoke-tested for no crash.

Typical attack path

1. Gain the ability to call libheif’s local writer/region API in a vulnerable process (version prior to 1.23.2), not by supplying a HEIF/AVIF file.
2. Invoke heif_region_item_add_region_inline_mask_data() with width/height that imply a larger mask than the provided mask_data_len.
3. Cause the application to retrieve the region mask via heif_region_get_mask_image() or heif_region_get_inline_mask_image().
4. Collect leaked adjacent heap bytes from the returned monochrome mask, or observe a crash if the over-read is unmapped.
5. No further integrity impact; there is no write primitive or remote file-based trigger.

How to detect it

This is a local API heap over-read with no file-based trigger, no known in-the-wild exploitation, and no named actors, so retrospective compromise evidence will be sparse. Focus on processes that author HEIF/AVIF region metadata with libheif < 1.23.2: application crash dumps and sanitizer reports citing heif_region_get_inline_mask_image, heif_region_get_mask_image, or heif_region_item_add_region_inline_mask_data; abnormal monochrome mask buffers whose size does not match declared width/height; and core dumps or ASan/MSan heap-buffer-overflow stacks in libheif. File-ingest logs, network captures, and malicious HEIF/AVIF samples are not useful indicators for this CVE. Absence of crashes does not prove the over-read did not occur, because a successful leak need not fault.

• heif_region_item_add_region_inline_mask_data
• heif_region_get_inline_mask_image
• heif_region_get_mask_image
• libheif/api/libheif/heif_regions.cc
• libheif.so.* (versions prior to 1.23.2)
• AddressSanitizer: heap-buffer-overflow ... heif_region_get_inline_mask_image

What your security team should do

• Patch libheif to 1.23.2+ on a normal cycle; this is not a KEV/ransomware emergency.
• Inventory which products actually call the writer region APIs versus decode-only use; deprioritize pure parsers.
• Treat statically linked and vendored copies as first-class: rebuild those artifacts, do not rely on OS package bumps alone.
• Until patched, restrict who can drive HEIF/AVIF authoring APIs and isolate those processes.
• Watch for crashes or unexpected mask-image sizes in writer-path services; there is no public exploit to hunt yet.
• Reassess if EPSS, KEV, or exploit-maturity status changes.