Skip to main content
OneCon26: Gain the advantage in the AI era. Oct. 20–22 in Las Vegas.Register Now
CVE Vulnerability Database
Vulnerability Database/CVE-2026-62289

CVE-2026-62289: libheif HEIF/AVIF DoS Vulnerability

CVE-2026-62289 is a denial of service flaw in libheif affecting HEIF and AVIF file processing that can crash applications or corrupt tiling results. This post covers the technical details, affected versions, and mitigation steps.

Updated:

CVE-2026-62289 Overview

CVE-2026-62289 is an integer underflow vulnerability [CWE-191] in libheif, an open-source HEIF and AVIF file format decoder and encoder. Versions 1.23.0 and earlier mishandle crafted files containing a clean aperture (clap) box that reduces an image dimension to zero. When heif_image_handle_get_image_tiling() is called on such a file, the clean aperture transformation is applied twice, triggering an underflow in Box_clap::left_rounded(). Debug builds abort on assertion, while release builds return corrupt crop data and zero-width tiling results. The issue is fixed in libheif 1.23.1.

Critical Impact

Applications that decode untrusted HEIF or AVIF images with libheif ≤ 1.23.0 can crash or produce corrupt tiling metadata when processing a crafted file.

Affected Products

  • libheif versions 1.23.0 and earlier
  • Applications and libraries embedding vulnerable libheif builds
  • HEIF and AVIF decoding pipelines using heif_image_handle_get_image_tiling()

Discovery Timeline

  • 2026-08-18 - CVE-2026-62289 published to NVD
  • 2026-08-19 - Last updated in NVD database

Technical Details for CVE-2026-62289

Vulnerability Analysis

The flaw exists in libheif's handling of the clean aperture transformation during image tiling. ImageItem::get_heif_image_tiling() returns dimensions that have already been transformed by the clap box. The function process_image_transformations_on_tiling() then applies the same clean aperture transformation a second time. When the first application reduces a dimension to zero, the second application passes zero into Box_clap::left_rounded().

Inside that function, the expression image_width - 1U underflows because image_width is an unsigned integer equal to zero. The result is 0xFFFFFFFF, which is then used to construct a Fraction(0xFFFFFFFF, 2). Debug builds hit an internal assertion and abort the process. Release builds continue execution and return a corrupt crop result together with a zero-width tiling structure that downstream code may consume unsafely.

The affected implementation spans three source files: libheif/image-items/image_item.cc, libheif/context.cc, and libheif/box.cc.

Root Cause

The root cause is unchecked arithmetic on an unsigned 32-bit width value combined with a redundant application of the clean aperture transformation. Neither the calling context nor Box_clap::left_rounded() validated that image_width was non-zero before subtracting one, allowing the wraparound to UINT32_MAX.

Attack Vector

An attacker crafts a HEIF or AVIF file containing a clap box whose parameters reduce a spatial dimension to zero. The attacker delivers the file to a target application that invokes heif_image_handle_get_image_tiling(). Exploitation requires user interaction to open or process the file, and the impact is limited to availability, resulting in a denial of service or corrupt output rather than code execution.

text
// Security patch in libheif/box.cc
// Fix clap transform double-application in image tiling (GHSA-jc8f-p23p-5hjg)

  // left = horizOff + (width-1)/2 - (clapWidth-1)/2

+  // Guard against image_width==0: `image_width - 1U` would underflow to
+  // UINT32_MAX and overflow the Fraction (GHSA-jc8f-p23p-5hjg).
+  if (image_width == 0) {
+    return 0;
+  }
+
   Fraction pcX = m_horizontal_offset + Fraction(image_width - 1U, 2U);
   Fraction left = pcX - (m_clean_aperture_width - 1) / 2;

Source: GitHub Commit f01870c

Detection Methods for CVE-2026-62289

Indicators of Compromise

  • Unexpected process aborts or SIGABRT signals in applications parsing HEIF or AVIF files
  • Log entries showing Invalid_clean_aperture errors after applying the 1.23.1 patch
  • Crashes originating in Box_clap::left_rounded() or process_image_transformations_on_tiling() stack frames

Detection Strategies

  • Inventory software dependencies to identify applications that statically or dynamically link libheif versions at or below 1.23.0
  • Scan container images and OS packages for the libheif package version and flag builds prior to 1.23.1
  • Fuzz-test HEIF and AVIF ingestion paths with crafted clap boxes that set output dimensions to zero

Monitoring Recommendations

  • Monitor endpoint telemetry for repeated crashes in image viewers, thumbnail services, and media indexing daemons
  • Alert on abnormal termination of server-side image processing workers handling user-supplied HEIF or AVIF uploads
  • Track ingestion of HEIF and AVIF files from untrusted sources through web application and email gateways

How to Mitigate CVE-2026-62289

Immediate Actions Required

  • Upgrade libheif to version 1.23.1 or later across all systems and container images
  • Rebuild and redeploy applications that statically link libheif against the patched release
  • Restrict acceptance of HEIF and AVIF uploads from untrusted sources until the update is deployed

Patch Information

The issue is fixed in libheif 1.23.1. The patch adds an early return in Box_clap::left_rounded() when image_width is zero and validates clap-derived dimensions in libheif/context.cc before assigning them to the image resolution. Details are available in the GitHub Security Advisory GHSA-jc8f-p23p-5hjg and the libheif v1.23.1 release notes.

text
// Security patch in libheif/context.cc
// Reject clap transforms that reduce the image to zero size

     for (const auto& prop : properties) {
       auto clap = std::dynamic_pointer_cast<Box_clap>(prop);
       if (clap) {
-        image->set_resolution(clap->get_width_rounded(),
-                              clap->get_height_rounded());
+        int clap_width = clap->get_width_rounded();
+        int clap_height = clap->get_height_rounded();
+        if (clap_width <= 0 || clap_height <= 0) {
+          return {heif_error_Invalid_input,
+                  heif_suberror_Invalid_clean_aperture,
+                  "Clean aperture (clap) reduces image to zero size"};
+        }
+
+        image->set_resolution(static_cast<uint32_t>(clap_width),
+                              static_cast<uint32_t>(clap_height));

         if (image->has_intrinsic_matrix()) {
           image->get_intrinsic_matrix().apply_clap(clap.get(), image->get_width(), image->get_height());

Source: GitHub Commit f01870c

Workarounds

  • Disable or block HEIF and AVIF decoding paths in exposed services until the patched library is deployed
  • Validate image dimensions returned by libheif and reject zero-width or zero-height results before further processing
  • Sandbox image parsing workers so that a crash in the decoder does not affect the parent application
bash
# Verify installed libheif version and upgrade to the patched release
dpkg -s libheif1 | grep -i version
apt-get update && apt-get install --only-upgrade libheif1
# Or build from source at the fixed tag
git clone https://github.com/strukturag/libheif.git
cd libheif && git checkout v1.23.1

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.

Try SentinelOne