CVE-2026-41071

What it actually does

CVE-2026-41071 is a heap out-of-bounds read in libheif 1.21.2 and earlier during parsing of crafted HEIF/AVIF sequence files. The parser trusts the sample count declared in the `saiz` box without validating that it is consistent with the track chunk table. When the declared sample count exceeds the chunks available, `SampleAuxInfoReader` advances past the end of the chunks vector and reads memory out of bounds. In practical terms, affected applications that use libheif to process untrusted image files may crash, disclose adjacent process memory, or experience undefined behavior during file parsing via `heif_context_read_from_file`. The CVSS score is 8.1, but exploitation requires the vulnerable software to parse a malicious file.

Why it matters to the business

Organizations using libheif directly or through image-processing, media-management, thumbnailing, document-ingestion, web-upload, messaging, or content-moderation pipelines may be exposed if they accept HEIF or AVIF files from untrusted sources. The most likely operational impact is denial of service through crashes of user-facing applications or backend media workers. In higher-risk contexts, out-of-bounds reads may expose sensitive process memory. This issue is not currently listed in CISA KEV, is not known to be ransomware-used, has low EPSS at 0.00302 with no 30-day increase, and has no known public exploit maturity, but it should still be prioritized where automated file parsing of user-supplied images occurs at scale.

How an attack unfolds

An attacker creates a malformed HEIF sequence file whose `saiz` box declares more auxiliary information samples than are represented by the track chunk table. The attacker then gets a vulnerable application to parse that file, for example by uploading it to an image-processing service, sending it through a workflow that generates thumbnails or previews, or convincing a user to open it in software linked against vulnerable libheif. During parsing, libheif calls `heif_context_read_from_file`, constructs `SampleAuxInfoReader`, and iterates according to the untrusted `saiz` sample count. Because the sample count is not checked against the chunks vector length, parsing advances beyond the valid vector bounds and reads heap memory out of range. Depending on allocator behavior, compiler options, and calling application error handling, this can produce a crash, a controlled denial of service, or potential memory disclosure. There are currently no named threat actors or known exploited-in-the-wild campaigns associated with this vulnerability.

How to fix it

Upgrade libheif to version 1.22.0 or later wherever it is used. Because libheif is often bundled into applications, containers, desktop packages, image libraries, and media services, remediation should include both direct dependencies and transitive/vendor-supplied copies. Rebuild statically linked applications against the fixed library. If immediate upgrade is not possible, reduce exposure by blocking or quarantining untrusted HEIF/AVIF sequence files, disabling HEIF/AVIF parsing in high-risk upload paths, processing untrusted media in a sandboxed worker with memory and CPU limits, isolating media converters from sensitive data, and enforcing crash restart/rate-limiting controls to reduce denial-of-service impact.

How to confirm the fix worked

Confirm that all deployed libheif instances report version 1.22.0 or later. Validate operating system packages, container images, application bundles, and statically linked binaries rather than relying only on system package inventory. Where feasible, run `heif-info --version`, package-manager queries, software composition analysis, container image scanning, or binary string inspection for libheif version evidence. Test exposed upload and media-processing paths to confirm HEIF/AVIF parsing is either disabled, sandboxed, or handled by a fixed library. Review crash telemetry after patching to ensure crashes involving `SampleAuxInfoReader`, `heif_context_read_from_file`, or HEIF/AVIF parsing no longer occur when malformed files are processed.

Typical attack path

1. Identify an application, service, or processing pipeline that accepts HEIF/AVIF images and uses libheif 1.21.2 or earlier.
2. Craft a HEIF sequence file with an inconsistent `saiz` box sample count that exceeds the number of samples covered by the track chunk table.
3. Deliver the file through an upload form, media ingestion API, messaging channel, email attachment, shared folder, or user-open workflow.
4. Trigger parsing by the vulnerable application, commonly during preview generation, metadata extraction, transcoding, validation, or thumbnail creation.
5. Cause `SampleAuxInfoReader` to iterate past the available chunks vector entries during `heif_context_read_from_file`.
6. Achieve process crash, service interruption, or possible exposure of adjacent heap memory depending on the application and runtime protections.

How to detect it

Look for evidence that malformed HEIF or AVIF files were processed before remediation. Relevant sources include application upload logs, media conversion logs, thumbnail generation logs, crash dumps, endpoint detection telemetry, container restart events, systemd or supervisor logs, web server access logs for image uploads, object-storage access logs, and application exception traces. Hunt for crashes or restarts occurring immediately after HEIF/AVIF uploads or processing jobs, especially logs referencing libheif parsing, `SampleAuxInfoReader`, `heif_context_read_from_file`, `saiz`, heap-buffer-overflow, out-of-bounds read, segmentation fault, or abort signals. For internet-facing services, correlate upload events with subsequent 5xx errors, worker process exits, container OOM/crash loops, or repeated submission of unusual `.heif`, `.heic`, `.avif`, or sequence-style files. If crash dumps are available, inspect stack traces for libheif frames and retain the triggering file for offline analysis. Because there are no known public exploit artifacts, known attacker infrastructure, or fixed malicious file hashes, detection should focus on behavioral and crash telemetry rather than static IOCs alone.

• SampleAuxInfoReader
• heif_context_read_from_file
• heap-buffer-overflow
• out-of-bounds read
• libheif
• saiz
• HEIF
• AVIF
• .heif
• .heic
• .avif
• Segmentation fault
• SIGSEGV
• AddressSanitizer: heap-buffer-overflow

What your security team should do

• Inventory applications, containers, and services that parse HEIF or AVIF files, especially upload, thumbnailing, media conversion, content moderation, document-processing, and messaging workflows.
• Prioritize upgrade to libheif 1.22.0 or later for internet-facing or automated file-processing services that accept untrusted media.
• Check vendor advisories and application release notes for products that bundle libheif, because affected copies may not appear as standalone system packages.
• Temporarily restrict HEIF/AVIF uploads or route them to sandboxed processing workers if patching cannot be completed quickly.
• Add monitoring for crashes or abnormal restarts in media-processing components, especially events referencing `SampleAuxInfoReader`, `heif_context_read_from_file`, heap-buffer-overflow, HEIF, AVIF, or malformed `saiz` boxes.
• Preserve suspicious HEIF/AVIF samples that triggered crashes for forensic analysis, but handle them in an isolated malware-analysis environment.
• Use software composition analysis and container scanning in CI/CD to prevent reintroduction of libheif 1.21.2 or earlier.