CVE-2026-41069

What it actually does

CVE-2026-41069 is an out-of-bounds read in libheif 1.21.2 and earlier when parsing malformed HEIF sequence metadata. A crafted file can set stco.entry_count to 0, resulting in no chunk entries, while also setting saio.entry_count to 0 so validation passes, and saiz.sample_count greater than 0 so SampleAuxInfoReader continues into chunked parsing. The parser then dereferences chunks[0] even though the chunks array is empty. The known impact is denial of service through process crash or abnormal termination of software that uses libheif to decode, inspect, thumbnail, transform, or otherwise process HEIF/AVIF content. The CVSS vector indicates network-reachable delivery is possible, no privileges are required, but user or application interaction with the malicious file is required; confidentiality and integrity impact are not expected from the described flaw.

Why it matters to the business

Organizations using applications, services, content pipelines, image-processing backends, document previewers, media libraries, or endpoint software linked against libheif may experience service disruption when a malicious HEIF/AVIF file is processed. The practical consequence is availability loss: upload handlers, thumbnail generators, image conversion jobs, messaging systems, web applications, or desktop applications may crash or repeatedly fail on attacker-supplied media. The EPSS score is currently low and stable, the issue is not listed in CISA KEV, and no public exploit maturity is reported, which lowers immediate exploitation urgency; however, because image parsers are often exposed indirectly through file uploads and automated processing, affected systems should still be patched or mitigated as part of normal vulnerability remediation.

How an attack unfolds

An attacker crafts a malformed HEIF sequence file with inconsistent auxiliary information metadata: zero chunk entries via stco.entry_count == 0, matching saio.entry_count == 0 to pass validation, and a positive saiz.sample_count to force auxiliary sample parsing. The attacker then delivers the file to software that uses vulnerable libheif versions, commonly through an upload form, image conversion workflow, media ingestion pipeline, email/message attachment, file preview feature, or by convincing a user to open the file in a vulnerable application. When the target application parses the file, libheif enters SampleAuxInfoReader chunked-mode logic and attempts to access chunks[0] even though no chunks were created. This produces an out-of-bounds read that can crash the process, causing denial of service. There is no indication from the supplied data that this vulnerability enables code execution or data theft.

How to fix it

Upgrade libheif to a version newer than 1.21.2 once the vendor-patched release is available from the official struktur/libheif project or the relevant operating-system/package maintainer. Because no fixed version was provided in the input, remediation teams should verify the current upstream advisory or distribution security bulletin before selecting a target version. For statically linked applications, rebuild and redeploy the consuming application after updating libheif; simply updating the system package may not fix bundled copies. For containerized workloads, rebuild images from patched base images and confirm the runtime library version inside the final image. Where immediate patching is not possible, reduce exposure by blocking or quarantining HEIF/AVIF uploads from untrusted users, disabling automatic preview/thumbnail generation for .heif, .heic, .avif, and related sequence files, enforcing file-type validation and size limits, isolating media processing workers, and configuring supervisors to restart crashed workers while rate-limiting repeated failures.

How to confirm the fix worked

Confirm exposure by inventorying libheif versions across servers, containers, workstations, and applications that process images. Affected versions are 1.21.2 and earlier. Check package-manager metadata, application dependency manifests, container SBOMs, and statically linked binaries where applicable. Validate remediation by confirming the runtime library reports a non-affected version or by verifying the vendor/distribution package includes the relevant fix. Exercise caution with proof-of-concept validation: only test in isolated non-production environments using controlled malformed HEIF files, and verify that the parser returns an error instead of crashing. Operationally, confirm that upload and media-processing paths either reject risky file types or process them inside constrained, monitored workers. Review crash telemetry before and after remediation to ensure crashes associated with HEIF/AVIF parsing cease.

Typical attack path

1. Identify an application, service, or endpoint workflow that accepts or processes HEIF/AVIF files using libheif 1.21.2 or earlier.
2. Create a malformed HEIF sequence file with stco.entry_count set to 0, saio.entry_count set to 0, and saiz.sample_count greater than 0.
3. Deliver the file through a reachable file-processing path such as image upload, media import, attachment preview, thumbnail generation, or user-opened file.
4. Wait for the vulnerable parser to process the file automatically or through user interaction.
5. Trigger an out-of-bounds read when libheif dereferences an empty chunks array during auxiliary sample information parsing.
6. Cause the processing application or worker process to crash, interrupting availability of the affected function or service.

How to detect it

To determine whether the vulnerability may already have been exploited, correlate HEIF/AVIF file ingestion events with application crashes, worker restarts, HTTP 5xx spikes, failed thumbnail or conversion jobs, and operating-system crash reports. Relevant log sources include web access logs for file uploads, object-storage or attachment-ingestion logs, media-processing queue logs, application error logs, container restart events, systemd/journald logs, crash dump collectors, EDR telemetry, and core-dump metadata. Look for crashes in processes that link to libheif or perform image decoding immediately after processing files with HEIF/AVIF extensions or MIME types such as image/heif, image/heic, image/avif, or image/heif-sequence. For forensic review, preserve the triggering file if available and inspect whether it contains HEIF box metadata involving stco, saio, and saiz with the suspicious relationship stco.entry_count == 0, saio.entry_count == 0, and saiz.sample_count greater than 0. Because exploitation causes denial of service rather than a stable compromise primitive, the strongest evidence is temporal correlation between a specific uploaded/opened media file and reproducible parser crashes. No named threat actors or ransomware use are reported in the supplied data.

• libheif
• SampleAuxInfoReader
• chunks[0]
• stco.entry_count == 0
• saio.entry_count == 0
• saiz.sample_count
• image/heif
• image/heic
• image/avif
• image/heif-sequence
• .heif
• .heic
• .avif
• Segmentation fault
• SIGSEGV
• core dumped

What your security team should do

• Inventory all software and services that use libheif, including image upload handlers, thumbnailers, media-processing jobs, desktop image viewers, mobile/desktop sync clients, containers, and statically bundled dependencies.
• Prioritize remediation for internet-facing or user-supplied file-processing systems, even though EPSS is low and the vulnerability is not currently in CISA KEV.
• Upgrade libheif 1.21.2 and earlier to a vendor-confirmed fixed release when available; rebuild applications and containers that bundle or statically link libheif.
• Temporarily restrict or sandbox HEIF/AVIF processing from untrusted sources until patched, especially in automated media pipelines.
• Add monitoring for repeated crashes in image-processing workers or services shortly after HEIF/AVIF uploads or attachment previews.
• Ensure media-processing services run with least privilege, resource limits, crash isolation, and automatic recovery to limit denial-of-service blast radius.
• Track upstream struktur/libheif advisories and distribution security updates because no exact fixed version was supplied.