CVE-2026-84446: libheif HEIF/AVIF Decoder DoS Vulnerability

CVE-2026-84446 Overview

CVE-2026-84446 is a denial-of-service vulnerability in libheif, an open-source HEIF and AVIF file format decoder and encoder. Crafted HEIF sequence timing and edit-list data cause Track::init_sample_timing_table() to compute an oversized m_num_output_samples value that exceeds the uint32_t counters in the decode loop. The comparison never terminates, bypassing the max_sequence_frames safeguard. The same code path also allocates memory outside the MemoryHandle accounting, enabling CPU and memory exhaustion from a small input file. The issue is fixed in libheif version 1.23.2.

Critical Impact
A small crafted HEIF file can trigger non-terminating decode loops and unbounded memory allocation, exhausting CPU and RAM on any application or service that decodes untrusted HEIF sequences with libheif.

Affected Products

libheif versions prior to 1.23.2
Applications embedding libheif for HEIF or AVIF sequence decoding
Server-side image processing pipelines that ingest untrusted HEIF media

Discovery Timeline

2026-09-18 - CVE-2026-84446 published to NVD
2026-09-21 - Last updated in NVD database

Technical Details for CVE-2026-84446

Vulnerability Analysis

The vulnerability is an infinite loop and unbounded resource consumption issue classified under [CWE-835]. Crafted sequence timing and edit-list data make Track::init_sample_timing_table() produce a logical m_num_output_samples value that overflows the uint32_t counters used by Track_Visual::decode_next_image_sample() and Track::get_next_sample_raw_data(). Because the counter can never reach the oversized target, the decoding loop never terminates.

Compounding the loop issue, the same sequence path repeatedly calls Box_stts::get_sample_duration() and allocates Chunk::m_sample_ranges and Track::m_presentation_timeline outside the MemoryHandle accounting. The max_sequence_frames cap intended to bound work is bypassed because it is evaluated against counters that overflow before the check succeeds.

Root Cause

The root cause is a type-width mismatch between the computed logical sample count and the 32-bit counters that gate the decode loops. Attacker-controlled edit-list repetition multiplies sample counts beyond UINT32_MAX, so loop termination conditions become unreachable. Related allocations grow proportionally without being charged against the configured memory budget.

Attack Vector

Exploitation requires only that a victim application decode an attacker-supplied HEIF file. No authentication or user interaction beyond opening the file is required. Any network-facing service that processes uploaded HEIF or AVIF sequences, such as image thumbnailers, content platforms, or messaging backends, is exposed.

text

// Security patch in libheif/sequences/chunk.cc
// Source: https://github.com/strukturag/libheif/commit/3a7a69ae325f652e48c026b8241ab25bedf44d9b

  m_next_sample_to_be_decoded = first_sample;

+  // Reserve the exact final size so the running offset check below is the only
+  // growth concern (no geometric reallocation). The aggregate over all chunks is
+  // accounted against max_total_memory by the owning Track before any chunk is
+  // built (GHSA-xw34-mjcp-jqh8, variants V2/V3), so no per-chunk limit check here.
+  m_sample_ranges.reserve(num_samples);
+
   for (uint32_t i=0;i<num_samples;i++) {
     SampleFileRange range;
     range.offset = file_offset;

Source: GitHub Commit 3a7a69ae

Detection Methods for CVE-2026-84446

Indicators of Compromise

Processes linked against libheif consuming sustained 100% CPU on a single thread while decoding a HEIF file.
Rapid resident memory growth in image-processing workers shortly after receiving small HEIF uploads (typically under a few hundred kilobytes).
HEIF files containing unusually large or repeated edts and stts box entries relative to file size.

Detection Strategies

Inventory all applications and container images that link libheif and flag versions below 1.23.2.
Monitor image-processing services for out-of-memory kills, hung worker processes, and abnormally long HEIF decode times.
Add pre-parsing validation at the ingest layer to reject HEIF files whose declared sample counts or edit-list repetition exceed sane thresholds.

Monitoring Recommendations

Alert on decode operations that exceed a configured wall-clock budget for a single media file.
Track per-request memory ceilings on services that decode user-supplied media and log breaches with the originating request identifier.
Enable core dumps or profiling on image workers so hung threads can be tied back to the offending input.

How to Mitigate CVE-2026-84446

Immediate Actions Required

Upgrade libheif to version 1.23.2 or later across all systems and container images.
Rebuild and redeploy any downstream applications that statically link libheif.
Enforce per-process CPU time and memory limits on services that decode untrusted HEIF or AVIF content.

Patch Information

The fix is included in libheif v1.23.2. The patch clamps Track::init_sample_timing_table() output, reserves the exact final size for Chunk::m_sample_ranges, and accounts related allocations against max_total_memory. Full details are published in GitHub Security Advisory GHSA-xw34-mjcp-jqh8 and the corresponding upstream commit.

Workarounds

Disable HEIF sequence decoding in applications that do not require it.
Sandbox image-decoding workers with strict cgroup CPU and memory limits and short timeouts.
Reject HEIF uploads at the network edge until libheif is upgraded on all backend processors.

bash

# Configuration example: enforce resource limits on a HEIF decoder service (systemd)
[Service]
CPUQuota=50%
MemoryMax=512M
TimeoutStartSec=10
LimitCPU=15