CVE-2026-32738

What it actually does

CVE-2026-32738 is a denial-of-service flaw in libheif 1.21.2 and earlier when parsing a malformed HEIF sequence file. A crafted file can set samples_per_chunk=0 in the stsc box, causing an unsigned integer underflow in chunk sample accounting. The malformed file is accepted during parsing, but when an application accesses the first frame or sample, libheif dereferences index 0 of an empty std::vector, resulting in a deterministic segmentation fault. The impact is availability loss of the calling process; there is no indicated confidentiality or integrity impact.

Why it matters to the business

Applications, desktop tools, web services, media pipelines, thumbnail generators, document processors, and image ingestion workflows that rely on libheif can be crashed by a malicious HEIF/AVIF file. This may interrupt user workflows, break automated media processing queues, or cause repeated service restarts if untrusted uploads are processed automatically. The CVSS availability impact is high, but current exploitation signals are low: EPSS is 0.00301 with no 30-day increase, no known KEV listing, no ransomware association, and no reported mature public exploitation.

How an attack unfolds

An attacker creates a small malformed HEIF sequence file containing an stsc box where samples_per_chunk is zero. The file is structured so libheif accepts it as parseable input and does not reject it during initial validation. The attacker then convinces a user to open the file or submits it to a service that decodes, previews, thumbnails, indexes, or otherwise accesses HEIF/AVIF frames using libheif. When the application attempts to access the first sample or frame, libheif uses corrupted chunk metadata and reads from an empty vector, causing a null-page read and segmentation fault. The result is a crash of the application or worker process handling the file.

How to fix it

Upgrade libheif to version 1.22.0 or later wherever it is directly installed or bundled into applications, containers, desktop packages, media services, or image-processing libraries. Rebuild dependent applications that statically link libheif. If immediate upgrade is not possible, restrict or disable HEIF/AVIF processing from untrusted sources, isolate media parsing in sandboxed worker processes, enforce file-type validation and size limits, and configure supervisors to restart crashed workers while rate-limiting repeated failures from the same source. Because the crafted file may parse successfully and only crash on frame access, do not rely solely on initial metadata parsing as a safety check.

How to confirm the fix worked

Confirm that all runtime and build environments use libheif 1.22.0 or later. Check package-manager versions, container images, application bundles, and statically linked dependencies. Validate that applications which process HEIF/AVIF content no longer crash when handling malformed sequence files with an stsc box containing samples_per_chunk=0. For services, test upload, preview, thumbnail, indexing, and transcoding paths, not only metadata parsing. Confirm that crash monitoring no longer records segmentation faults in libheif code paths during HEIF/AVIF processing.

Typical attack path

1. Identify an application or service that uses libheif 1.21.2 or earlier to process HEIF/AVIF content.
2. Generate or obtain a malformed HEIF sequence file with samples_per_chunk=0 in the stsc box.
3. Deliver the file through a user-opened attachment, shared media file, upload form, image-processing API, content management system, or media ingestion pipeline.
4. Trigger frame/sample access by previewing, thumbnailing, transcoding, indexing, or opening the file.
5. Cause the libheif-consuming process to terminate with a segmentation fault, producing denial of service.

How to detect it

To determine whether this was already exploited, review application logs, crash dumps, endpoint telemetry, and service supervisor logs for segmentation faults in processes that parse HEIF/AVIF files. Focus on upload services, thumbnailers, media transcoders, image preview components, content management systems, document processors, and desktop image viewers. Correlate crashes with recently received or processed .heif, .heic, .avif, or HEIF sequence files, especially repeated crashes caused by the same uploaded object, sender, client IP, user agent, or file hash. Inspect crash stacks for libheif functions, Chunk construction/sample mapping, frame access, or std::vector out-of-range/null-page reads. If available, perform forensic triage of suspect media files by parsing BMFF/HEIF box structure and looking for an stsc box entry where samples_per_chunk equals 0. There are no known named threat actors, KEV exploitation reports, or ransomware campaigns associated with this issue as of the provided data.

• libheif
• SIGSEGV
• Segmentation fault
• std::vector
• samples_per_chunk=0
• stsc
• Chunk::Chunk
• m_last_sample
• heif_context_get_image_handle
• heif_decode_image
• .heif
• .heic
• .avif

What your security team should do

• Inventory systems, applications, containers, and third-party products that process HEIF or AVIF files using libheif.
• Prioritize upgrades for internet-facing upload services, media processing pipelines, email/file preview systems, and desktop applications likely to open untrusted image files.
• Upgrade libheif to 1.22.0 or later and rebuild any software that statically links the library.
• Temporarily restrict HEIF/AVIF uploads or route them through isolated, low-privilege sandbox workers until patching is complete.
• Add monitoring for repeated segmentation faults or worker crashes associated with HEIF/AVIF processing.
• Search historical crash logs and application logs for libheif-related SIGSEGV events after processing user-supplied HEIF/AVIF files.
• Because EPSS is low, not KEV-listed, and no mature exploitation is reported, handle through normal vulnerability remediation SLAs unless the affected service is externally exposed or business-critical.