CVE-2026-50142 in libheif
Summary
by MITRE • 08/18/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/19/2026
The vulnerability identified within libheif versions ranging from 1.19.0 to 1.23.0 represents a critical heap-based resource exhaustion flaw triggered by maliciously crafted HEIF files utilizing the msf1 sequence brand. As a widely used library for decoding and encoding High Efficiency Image File Format (HEIF) and AVIF content, libheif is frequently integrated into image processing pipelines, web browsers, and operating system components that handle media ingestion. The core of this vulnerability lies in the improper validation of sample count parameters during the parsing of sequence boxes, specifically within the Box_stsz::parse function located in libheif/sequences/seq_boxes.cc. When processing variable-size samples, the library correctly applies a limit defined by max_sequence_frames to prevent excessive memory consumption. However, in fixed-size mode, this protective boundary is entirely bypassed because the code fails to enforce any upper bound on the attacker-controlled sample_count field. This oversight allows an adversary to specify an arbitrarily large number of frames, directly influencing subsequent allocation decisions without triggering immediate validation errors.
The exploitation path extends further into libheif/sequences/track.cc where the Track::load function performs arithmetic operations involving current_sample_idx and samples_per_chunk using 32-bit integer types. This implementation introduces a classic integer overflow vulnerability that facilitates the bypass of internal consistency checks designed to limit memory usage. By carefully crafting input values, an attacker can induce a wraparound effect in these calculations, resulting in significantly smaller computed totals than intended by the security logic. These manipulated values are then passed to the Chunk::Chunk constructor, which proceeds to allocate heap memory based on the flawed arithmetic result rather than the actual malicious intent encoded in the file header. Consequently, while the internal checks may appear satisfied due to the wraparound, the underlying allocation mechanism is tricked into reserving resources that far exceed system limits or available physical memory.
The operational impact of this vulnerability is severe, primarily manifesting as a denial-of-service condition through catastrophic memory exhaustion. When the Chunk::Chunk() path executes with unbounded parameters derived from the overflowed calculations, it attempts to allocate gigabytes of contiguous heap space. This massive allocation request typically exceeds the available virtual address space or physical RAM on standard systems, causing the process to crash abruptly due out-of-memory errors or become completely stalled as the operating system struggles to satisfy the request. For applications that rely on libheif for real-time image processing or serve user-uploaded content, this can lead to service unavailability and potential instability in dependent services. The vulnerability is classified under CWE-190 Integer Overflow or Wraparound due to the flawed arithmetic logic and CWE-787 Out-of-bounds Write if the allocation leads to subsequent buffer overflows during data population, though the primary immediate effect is resource exhaustion categorized as CWE-400 Uncontrolled Resource Consumption.
From a threat intelligence perspective, this vulnerability aligns with ATT&CK technique T1496 Resource Hijacking, specifically sub-technique T1496.002 Denial of Service via Memory Exhaustion. Attackers can leverage this flaw to disrupt services without needing code execution capabilities, making it an attractive vector for simple denial-of-service attacks against media processing infrastructure. The issue was addressed in version 1.23.0 by implementing strict bounds checking on sample counts regardless of the sample size mode and correcting the arithmetic operations to prevent wraparound exploits. Organizations utilizing libheif should prioritize upgrading to version 1.23.0 or later to mitigate this risk. Additionally, defensive measures such as deploying input validation gateways that limit file sizes and monitoring for unusual memory allocation patterns can provide supplementary protection against exploitation attempts in environments where immediate patching is not feasible.