CVE-2026-62377 in libheif
Summary
by MITRE • 08/19/2026
libheif is a HEIF and AVIF file format decoder and encoder. In 1.23.0 and earlier, a crafted HEIF sequence accepted by heif_context_read_from_memory() can leave the context with no registered sequence tracks and crash when heif_context_get_track(ctx, 0) is called. HeifContext::get_track() in libheif/context.cc executes assert(has_sequence()) before its normal error handling, so assert-enabled builds abort instead of allowing the public wrapper in libheif/api/libheif/heif_sequences.cc to return null. In release builds, removing the assertion lets the track_id zero path dereference m_tracks.begin()->second on an empty map, which is undefined behavior and typically crashes. The issue is reachable through documented public APIs after parsing attacker-controlled bytes. This issue is fixed in version 1.23.1.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/19/2026
The vulnerability identified within libheif versions up to 1.23.0 represents a critical failure in input validation and state management during the processing of HEIF and AVIF file formats. Libheif serves as a widely adopted library for decoding and encoding these image container standards, which are increasingly prevalent due to their superior compression efficiency compared to traditional JPEG or PNG formats. The core issue arises when the function heif_context_read_from_memory processes a specifically crafted malicious input sequence. This malformed data causes the internal context object to reach an inconsistent state where it registers no valid sequence tracks despite appearing to have successfully parsed the file header and initial metadata structures.
The technical root cause lies in the implementation of HeifContext::get_track within the source file context.cc. The function is designed to retrieve a track by its identifier, but prior to executing standard error handling logic that would typically return an error code or null pointer for invalid requests, it executes an assertion check via has_sequence(). In debug builds where assertions are enabled, this leads directly to program termination through abort signals rather than graceful error recovery. This behavior exposes the application to denial-of-service conditions if the library is integrated into a service that processes untrusted HEIF content and runs with debugging symbols or assert checks active.
In release builds, the assertion mechanism is typically disabled by compiler flags, which alters the execution path but does not resolve the underlying logical flaw. Without the aborting assertion, the code proceeds to dereference m_tracks.begin()->second on an empty map container. Accessing elements of a standard library sequence or associative container that has been emptied results in undefined behavior according to C++ standards. In practical terms, this almost invariably leads to segmentation faults or memory corruption crashes because begin() returns an iterator past the end for empty containers, and dereferencing such an iterator is illegal. This makes the vulnerability particularly dangerous as it can be triggered remotely through documented public APIs without requiring any special privileges beyond the ability to supply input data.
The operational impact of this vulnerability extends beyond simple application crashes. Because libheif is often used in backend services for image processing, photo galleries, and media conversion pipelines, a successful exploit allows an attacker to cause denial-of-service against these systems. Furthermore, while the primary manifestation described is a crash due to undefined behavior, memory corruption vulnerabilities can sometimes be leveraged for arbitrary code execution depending on the specific compiler optimizations, heap allocator state, and surrounding application logic. The fact that this flaw is reachable through public APIs means it does not require internal knowledge of the library's structure, lowering the barrier for exploitation significantly.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation, as the parser fails to ensure that the parsed data results in a valid and consistent internal state before allowing further operations on that state. It also relates closely to CWE-476 NULL Pointer Dereference or more accurately CWE-825 Expired Pointer Dereference depending on how the empty map iterator is handled by the specific runtime environment, though technically it falls under undefined behavior stemming from improper container access. In terms of the MITRE ATT&CK framework, this represents a technique for Denial of Service (T1499) and potentially Initial Access if used to disrupt security monitoring or availability services that rely on image parsing capabilities.
Mitigation strategies must prioritize immediate updates to libheif version 1.23.1 or later, where the developers have addressed the logic error by ensuring proper state validation before track access. For systems unable to update immediately, implementing strict input sanitization at the application layer is recommended. This includes validating file headers and structure integrity using external tools or libraries that enforce stricter compliance with HEIF standards before passing data to libheif. Additionally, running services in sandboxed environments with limited privileges can mitigate the impact of potential crashes by preventing them from affecting critical system resources or other processes. Regular security audits focusing on parser robustness and state consistency checks are essential for maintaining resilience against such input-driven vulnerabilities.