Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-08-18T22:17:03.167Z",
  "pubdate": "2026-08-18T22:17:03.167Z",
  "executiveSummary": "A denial of service vulnerability exists in libheif versions 1.23.0 and earlier, specifically within the HEIF sequence processing logic.\nThe vulnerability is triggered when a crafted HEIF sequence is processed by the heif_context_read_from_memory() function, leaving the context devoid of any registered sequence tracks.\nSubsequent calls to the public API function heif_context_get_track(ctx, 0) result in application crashes.\nIn debug or assertion-enabled builds, the root cause manifests as an unhandled assertion failure via assert(has_sequence()) inside HeifContext::get_track() located in libheif/context.cc, which bypasses standard error handling.\nIn release builds, the absence of assertions leads to undefined behavior due to a null pointer or invalid iterator dereference on an empty map via m_tracks.begin()->second when evaluating track ID zero paths.\nAn attacker can achieve exploitation by supplying malformed, attacker-controlled bytes via documented public APIs, requiring no special authentication or privileges.\nThe risk implication is primarily availability disruption, causing application crashes upon parsing malicious input files.",
  "technicalDetails": "The vulnerability affects libheif versions 1.23.0 and earlier, impacting the HEIF and AVIF file format decoder and encoder components.\nThe vulnerable component resides in libheif/context.cc within the HeifContext::get_track() function, and in libheif/api/libheif/heif_sequences.cc which exposes the public wrapper.\nThe attack vector is reachable through documented public APIs after parsing attacker-controlled bytes, specifically utilizing the heif_context_read_from_memory() function to ingest a crafted HEIF sequence.\nAuthentication requirements, privilege requirements, and network exposure are not strictly defined by network layers, but the flaw is exposed whenever an application parses untrusted HEIF or AVIF files using the affected library functions.\nThe step-by-step attack flow begins when an application passes a crafted HEIF sequence to heif_context_read_from_memory().\nDue to the crafted structure of the input bytes, the resulting internal context state contains no registered sequence tracks.\nWhen the calling application or public API wrapper subsequently invokes heif_context_get_track(ctx, 0), execution flows into HeifContext::get_track() in libheif/context.cc.\nIn assert-enabled builds, the function executes assert(has_sequence()) prior to executing normal error handling logic, causing the application to immediately abort.\nIn release builds where assertions are stripped, removing the assertion check allows the track_id zero path to attempt a dereference of m_tracks.begin()->second on an empty map.\nThis map dereference constitutes undefined behavior, which typically results in an application crash.\nThe post-exploitation impact is limited to a denial of service via application termination, as no arbitrary code execution vector is described by this specific control flow failure."
}