CVE-2026-84446

What it actually does

A logic flaw in libheif’s HEIF sequence timing and edit-list handling lets crafted metadata cause Track::init_sample_timing_table() to compute a logical output-sample count larger than the uint32_t counters used by Track_Visual::decode_next_image_sample() and Track::get_next_sample_raw_data(). Those loops can never meet their termination condition, so decode or raw-sample extraction does not stop and max_sequence_frames is bypassed. The same path repeatedly calls Box_stts::get_sample_duration() and grows Chunk::m_sample_ranges and Track::m_presentation_timeline outside MemoryHandle accounting, producing unbounded CPU and heap use from a small file. Impact is availability only: hang or out-of-memory process death, not disclosure or integrity loss.

Why it matters to the business

Any service that decodes untrusted HEIF or AVIF with libheif before 1.23.2 can be taken down by one compact file—upload pipelines, thumbnailers, transcoders, messaging attachments, and document previewers are typical blast radius. Worker pools can stall, nodes can OOM, and picture-handling features stay unavailable until processes restart. The advisory is about 16 days old, is not on the CISA KEV list, has no reported ransomware or in-the-wild use, and exploit maturity is none; the CVSS profile is still unauthenticated, no-user-interaction availability loss, so unpatched internet-facing decoders remain an operational outage risk.

How an attack unfolds

An unauthenticated attacker supplies a compact HEIF sequence whose timing and edit-list data make the decoder compute an oversized output-sample count. The file is introduced through any path that causes libheif to parse it—upload, attachment, object-store ingest, or server-side fetch and transcode. On libheif before 1.23.2, timing-table initialization stores that inflated count; later sample-decode or raw-sample loops compare against 32-bit counters that never catch up, so the thread spins while also allocating timeline and chunk-range structures without the usual memory caps. The process stops making progress, burns CPU and RAM, and may be killed, denying service to other work on that process or node. This issue does not imply remote code execution or data theft.

How to fix it

Upgrade libheif to 1.23.2 or later on every host and container that links or vendors the library, then rebuild and redeploy consumers so they load the fixed binary. Where upgrade cannot be immediate, stop decoding untrusted HEIF/AVIF sequences, run decoders under strict CPU, memory, and wall-clock limits, isolate decode in disposable sandboxes, and quarantine unusual sequence or edit-list files at the edge. Inventory direct, vendored, and statically linked copies—not only OS packages—and treat each as in-scope until 1.23.2 or newer is confirmed.

How to confirm the fix worked

Confirm runtime libheif is 1.23.2 or newer via package metadata, linked-library version, SBOM, or application dependency reports, including static binaries and container images. After upgrade, decode a set of legitimate HEIF/AVIF stills and sequences under resource limits and verify they complete. For exposure, search images and SBOMs for libheif below 1.23.2 and for components that accept HEIF/AVIF from untrusted users.

Typical attack path

1. Supply a HEIF or AVIF sequence whose timing and edit-list metadata inflate the logical output-sample count.
2. Deliver that file to an application or service that decodes HEIF/AVIF with libheif before 1.23.2 (upload, attachment, preview, or transcode).
3. Cause the library to initialize track timing and then run sample-decode or raw-sample extraction.
4. Trigger a non-terminating decode loop and/or allocations outside MemoryHandle limits, exhausting CPU and memory.
5. Leave the decoder process hung or crashed so the service stays unavailable until restart or isolation.

How to detect it

No named campaign or public exploit is reported, so hunt for effects rather than a fixed payload. Review decoder, thumbnail, and transcode logs around HEIF/AVIF ingest for requests that never complete, worker timeouts, OOM-killer events, and repeated process restarts. On hosts, inspect core dumps and crash reports for stacks in libheif track timing initialization, visual sample decode, or raw-sample extraction, and confirm the loaded library was older than 1.23.2. Correlate with access logs that processed image/heif, image/heic, or image/avif immediately before the hang. Successful abuse of this bug typically leaves little persistent malware-like residue beyond resource exhaustion artifacts.

• init_sample_timing_table
• decode_next_image_sample
• get_next_sample_raw_data
• Box_stts::get_sample_duration
• m_presentation_timeline
• m_sample_ranges

What your security team should do

• Upgrade libheif to 1.23.2 or later everywhere it is linked or vendored; prioritize internet-facing decode, upload, and transcode paths.
• Inventory SBOMs, containers, and statically linked binaries for libheif older than 1.23.2.
• Until patched, enforce CPU, memory, and time limits on decoder workers and isolate untrusted HEIF/AVIF decode.
• Temporarily reject or sandbox untrusted HEIF/AVIF sequences at the perimeter if decode cannot be upgraded immediately.
• Watch decoder processes for hangs, unbounded RSS growth, OOM kills, and restart loops after HEIF/AVIF ingest.
• No KEV listing or known active exploitation; still treat unauthenticated availability loss as urgent for public decode surfaces.