Description

libheif is a HEIF and AVIF file format decoder and encoder. From 1.19.0 until 1.23.0, a crafted HEIF sequence accepted by heif_context_read_from_memory() with the msf1 sequence brand can cause unbounded heap allocation. In libheif/sequences/seq_boxes.cc, Box_stsz::parse() applies max_sequence_frames only to variable-size samples, so fixed-size mode accepts an attacker-controlled sample_count without a bound. In libheif/sequences/track.cc, Track::load() also adds current_sample_idx and samples_per_chunk in 32-bit arithmetic, allowing the consistency check to be bypassed by wraparound. The resulting values reach the Chunk::Chunk() allocation path, which can consume gigabytes of memory and crash or stall the process through memory exhaustion. This issue is fixed in version 1.23.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-18T22:16:52.633Z",
  "pubdate": "2026-08-18T22:16:52.633Z",
  "executiveSummary": "An unbounded heap allocation vulnerability exists in libheif versions 1.19.0 through 1.22.x, affecting the HEIF and AVIF file format decoder and encoder. The flaw is triggered when a crafted HEIF sequence with the msf1 sequence brand is processed via heif_context_read_from_memory(). This vulnerability allows an attacker to cause excessive memory consumption, leading to a denial of service through process crashes or system stalls.\nThe risk implication is high for applications processing untrusted HEIF or AVIF imagery, as memory exhaustion can disrupt dependent services. The attack requires no authentication or special privileges, relying entirely on the victim application parsing a maliciously crafted media file.",
  "technicalDetails": "The root cause of the vulnerability spans multiple components in libheif, specifically within libheif/sequences/seq_boxes.cc and libheif/sequences/track.cc. In Box_stsz::parse(), the protection mechanism max_sequence_frames is applied exclusively to variable-size samples. Consequently, fixed-size sample mode fails to validate the attacker-controlled sample_count against an upper bound.\nFurthermore, in Track::load(), the calculation adds current_sample_idx and samples_per_chunk utilizing 32-bit arithmetic. This implementation introduces an integer wraparound condition that bypasses critical consistency checks. The unvalidated and wrapped values propagate directly to the Chunk::Chunk() allocation path.\nThe step-by-step attack flow involves an attacker supplying a specially crafted HEIF sequence utilizing the msf1 sequence brand to an application invoking heif_context_read_from_memory(). The parser evaluates the fixed-size sample table in Box_stsz::parse() without enforcing size constraints, while the arithmetic operations in Track::load() wrap around 32-bit boundaries to evade validation. The resultant large allocation request forces the system to consume gigabytes of heap memory in Chunk::Chunk(), rapidly exhausting available system resources and causing a denial of service via memory exhaustion.\nThe vulnerability affects libheif versions 1.19.0 up to, but not including, version 1.23.0. Exploitation requires processing a malicious input file, with no prior authentication or administrative privileges needed."
}