CVE-2026-32741

What it actually does

CVE-2026-32741 is a heap buffer overflow in libheif versions 1.21.2 and earlier when decoding HEIF files that contain a mask image. The vulnerable code path in MaskImageCodec::decode_mask_image() copies attacker-controlled iloc extent data into a heap-allocated pixel buffer using a memcpy length derived from the file, while the destination buffer is sized from the image dimensions. A crafted HEIF file can declare dimensions that produce a smaller allocation but provide a larger iloc extent, causing memory corruption. The most likely impacts are application crash and denial of service; limited memory corruption could also alter process state, though the published CVSS indicates no expected confidentiality impact and low integrity impact. Exploitation requires a user or automated workflow to process a malicious image file.

Why it matters to the business

Organizations using libheif directly or through image-processing software, content-management systems, media pipelines, document preview services, thumbnail generators, or desktop applications may be exposed if untrusted HEIF/AVIF files are decoded. A successful attack can crash image-processing services, disrupt upload or preview workflows, and potentially affect availability of systems that process user-supplied media. The issue is not currently listed in CISA KEV, has low EPSS, no known public exploit maturity in the provided data, and no ransomware association, so urgency is primarily driven by whether the organization processes untrusted image files at scale or in internet-facing workflows.

How an attack unfolds

An attacker creates a malformed HEIF file containing a mask image box and associated metadata crafted to reach the vulnerable decode branch. The file uses an mskC property with bits_per_pixel set to 8 and an ispe property declaring an even width of at least 64 so the decoder uses the vulnerable single-copy path. The attacker then sets the iloc extent to reference more data than fits in the pixel buffer allocated from the declared image dimensions. When a vulnerable application or service using libheif 1.21.2 or earlier decodes the file, MaskImageCodec::decode_mask_image() calls memcpy with the attacker-controlled extent length, overflowing the heap buffer. Depending on allocator behavior and surrounding memory layout, the result may be a crash, denial of service, or limited corruption of process memory.

How to fix it

Upgrade libheif to version 1.22.0 or later wherever it is used. Because libheif is commonly embedded or consumed indirectly, patch both system packages and bundled application dependencies, including container images, desktop applications, media-processing services, thumbnailers, preview generators, and language bindings that package libheif. If immediate upgrade is not possible, reduce exposure by blocking or quarantining untrusted HEIF/AVIF uploads, disabling HEIF/AVIF decoding in high-risk workflows, isolating image-processing workloads in sandboxes or containers with strict resource limits, and ensuring crash-only failures do not take down broader services. Rebuild dependent software against the fixed library after upgrading.

How to confirm the fix worked

Confirm that all installed and bundled libheif versions report 1.22.0 or later. On Linux systems, check package manager inventories and dynamic linking paths for libheif.so; in containers, scan image layers and runtime filesystems. For applications that statically link or vendor libheif, verify the embedded source or binary provenance rather than relying only on OS package versions. Exercise representative HEIF/AVIF upload, preview, thumbnail, and conversion workflows after patching to ensure functionality remains intact. Where safe test harnesses are available, validate that malformed HEIF mask-image samples no longer crash the decoder and are rejected or handled safely.

Typical attack path

1. Identify an application, service, or automated pipeline that decodes HEIF or AVIF images using libheif 1.21.2 or earlier.
2. Craft a HEIF file containing a mask image with mskC bits_per_pixel = 8 and an ispe width that is even and at least 64 pixels.
3. Set the file's iloc extent data length larger than the destination pixel buffer derived from the declared image dimensions.
4. Deliver the crafted image through an upload form, email attachment, messaging channel, shared folder, content feed, or other workflow that causes server-side or client-side decoding.
5. Trigger image parsing, thumbnail generation, preview rendering, metadata extraction, or conversion.
6. Cause heap memory corruption in MaskImageCodec::decode_mask_image(), resulting in process crash, service disruption, or potentially limited integrity impact.

How to detect it

To determine whether exploitation may have already occurred, review logs from applications and services that accept or process HEIF/AVIF images, including upload services, media converters, thumbnail generators, preview/rendering services, desktop crash reporters, container orchestrator events, system journals, and endpoint telemetry. Look for crashes or abnormal restarts of processes linked to libheif shortly after handling .heif, .heic, or .avif files. Prioritize events showing heap corruption, segmentation faults, aborts, allocator errors, or stack traces containing MaskImageCodec::decode_mask_image(). Correlate crash timestamps with recently uploaded or received image files and preserve suspicious samples for offline analysis in an isolated environment. Inspect suspect files for HEIF mask-image structures such as mski and mskC boxes and unusually large iloc extents relative to declared image dimensions. Because no named threat actor, KEV listing, ransomware use, or public exploit maturity is provided, detection should focus on crash forensics and malformed media artifacts rather than actor-specific infrastructure.

• MaskImageCodec::decode_mask_image
• libheif
• heap-buffer-overflow
• heap buffer overflow
• AddressSanitizer: heap-buffer-overflow
• malloc(): corrupted top size
• malloc(): invalid size
• free(): invalid next size
• corrupted double-linked list
• Segmentation fault
• SIGSEGV
• SIGABRT
• .heif
• .heic
• .avif
• mski
• mskC
• iloc

What your security team should do

• Inventory systems and applications that process HEIF or AVIF files, especially internet-facing upload, preview, thumbnail, and conversion services.
• Prioritize upgrading libheif to 1.22.0 or later in services that process untrusted media files.
• Patch container base images and application images, then redeploy rather than only updating host packages.
• Review third-party applications and libraries that bundle libheif and obtain vendor-fixed builds where necessary.
• Temporarily restrict HEIF/AVIF ingestion from untrusted sources if patching cannot be completed quickly.
• Run media-processing workloads with least privilege, filesystem isolation, seccomp/AppArmor/SELinux controls, and memory/process supervision to limit blast radius from decoder crashes.
• Monitor image-processing services for crashes, abnormal restarts, and malformed HEIF files containing mask-image metadata.
• Add file-type validation and content scanning at upload boundaries, but do not rely on extension or MIME type alone.