CVE-2026-32740

What it actually does

This vulnerability is a heap-based buffer overflow in libheif's HEIF/AVIF grid tile compositing logic. A crafted HEIF or AVIF image using a 1×4 grid of odd-height tiles can cause the decoder to write 64 bytes beyond the end of a chroma plane heap allocation during normal image decoding. The overflow bytes are attacker-controlled Cb/Cr pixel data. In vulnerable builds, this can corrupt adjacent heap memory and may lead to process crash, memory corruption, or potentially arbitrary code execution in the context of the application performing image decoding.

Why it matters to the business

Applications, services, or workflows that process HEIF or AVIF images with vulnerable libheif versions could be crashed or potentially compromised by a malicious image file. This affects image upload pipelines, media processing services, desktop viewers, messaging clients, web applications, content moderation systems, document converters, and any downstream product that relies on libheif. Although the current EPSS is low and there is no known CISA KEV listing or public exploit maturity reported, the flaw has high technical severity because successful exploitation could impact confidentiality, integrity, and availability of the decoding application.

How an attack unfolds

An attacker crafts a malicious HEIF or AVIF file with a specific 1×4 grid layout and odd-height tiles so that libheif miscalculates or mishandles chroma plane compositing boundaries. The attacker then delivers the file to a target path that automatically or interactively decodes images, such as an upload endpoint, preview generator, thumbnailer, media indexing service, email attachment viewer, chat client, image converter, or desktop image viewer. When the vulnerable application decodes the file using libheif 1.21.2 or earlier, the decoder writes 64 bytes of attacker-controlled chroma data past the heap allocation. Depending on allocator behavior, memory layout, compiler hardening, sandboxing, and the consuming application's privileges, this may cause a denial of service through a crash or may be developed into memory corruption capable of code execution.

How to fix it

Upgrade libheif to version 1.22.0 or later wherever it is used directly or bundled transitively in applications, containers, operating system packages, desktop software, media services, or image-processing libraries. Rebuild statically linked applications and redeploy containers or appliances that include vulnerable libheif copies. If immediate upgrade is not possible, temporarily disable HEIF/AVIF processing, block HEIF/AVIF uploads from untrusted users, route decoding through a sandboxed worker with strict resource and privilege limits, and ensure crash isolation for thumbnailing or conversion services. Treat vendor-supplied applications that bundle libheif separately, because upgrading the system package may not fix embedded copies.

How to confirm the fix worked

Confirm that all runtime and bundled copies of libheif report version 1.22.0 or later. Validate package manager inventories, container image scans, SBOMs, statically linked binaries, and application vendor advisories. Test representative HEIF and AVIF processing paths after upgrade to ensure decoding still functions. For exposure validation, identify services and clients that accept .heic, .heif, or .avif files and confirm they no longer use libheif 1.21.2 or earlier. Where feasible, use a controlled regression test or vendor-provided proof test in a non-production environment to verify that the crafted grid tile condition no longer causes a crash or sanitizer-detected heap overflow.

Typical attack path

1. Identify an application, service, or client that accepts or previews HEIF or AVIF images and uses libheif 1.21.2 or earlier.
2. Craft a malicious HEIF/AVIF image containing a 1×4 grid of odd-height tiles that triggers the vulnerable grid tile compositing path.
3. Deliver the image through an upload form, media processing queue, message attachment, email attachment, shared folder, web page, or other content ingestion path.
4. Wait for the target application or background service to decode, thumbnail, convert, scan, or preview the image.
5. Trigger a 64-byte attacker-controlled heap overflow during chroma plane compositing.
6. Cause process termination or attempt to leverage heap corruption for further exploitation within the privileges of the decoding process.

How to detect it

Look for evidence that HEIF or AVIF files from untrusted sources caused crashes, memory corruption, or abnormal exits in applications that use libheif. Relevant log sources include application logs for upload/preview/thumbnail/conversion services, web server access logs for image uploads, media worker logs, container stdout/stderr, systemd journals, crash reporters, EDR process telemetry, core dump metadata, and sanitizer logs from hardened builds. Investigate segmentation faults, aborts, heap corruption messages, or AddressSanitizer reports involving libheif during processing of .heic, .heif, or .avif files. Correlate crashes with recent file submissions, message attachments, conversion jobs, thumbnail requests, or image preview activity. Preserve suspicious image files, associated request metadata, sender/uploader information, and core dumps for offline analysis. Since there are no public indicators tied to a known campaign and exploit maturity is reported as none, detection should focus on behavioral evidence of attempted parsing exploitation rather than fixed network indicators.

• AddressSanitizer: heap-buffer-overflow
• heap-buffer-overflow
• libheif
• HEIF
• AVIF
• .heic
• .heif
• .avif
• Segmentation fault
• SIGSEGV
• malloc(): corrupted top size
• malloc(): invalid size
• free(): invalid next size
• double free or corruption
• corrupted size vs. prev_size

What your security team should do

• Prioritize upgrades for internet-facing image upload, preview, thumbnailing, conversion, and content moderation services that process untrusted HEIF or AVIF files.
• Upgrade all libheif deployments to 1.22.0 or later, including container images, build pipelines, desktop packages, and vendor-bundled copies.
• Inventory applications that process .heic, .heif, and .avif files, because exposure may exist through indirect dependencies rather than explicit use of libheif.
• Apply sandboxing, least privilege, seccomp/AppArmor/SELinux profiles, memory-safe worker isolation, and crash containment around image decoding services.
• Temporarily restrict or quarantine HEIF/AVIF uploads from untrusted sources until vulnerable components are patched.
• Monitor crash logs, media processing failures, and sanitizer reports for heap-buffer-overflow events involving libheif or HEIF/AVIF decoding.
• Because the vulnerability is not currently in CISA KEV and EPSS is low, align urgency to exposure: patch internet-facing and automated processing paths first, then internal and user-interactive clients.