Skip to main content

libheif EUVDEUVD-2026-30980

| CVE-2026-32814 MEDIUM
Information Exposure (CWE-200)
2026-05-19 GitHub_M
6.5
CVSS 3.1 · GitHub Advisory
Share

Severity by source

GitHub Advisory PRIMARY
6.5 MEDIUM
AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N
SUSE
MEDIUM
qualitative
Red Hat
6.5 MEDIUM
qualitative

Primary rating from GitHub Advisory.

CVSS VectorGitHub Advisory

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N
Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
Required
Scope
Unchanged
Confidentiality
High
Integrity
None
Availability
None

Lifecycle Timeline

3
Patch available
May 19, 2026 - 21:02 EUVD
Source Code Evidence Fetched
May 19, 2026 - 20:48 vuln.today
Analysis Generated
May 19, 2026 - 20:48 vuln.today

DescriptionGitHub Advisory

libheif is a HEIF and AVIF file format decoder and encoder. In versions 1.21.2 and prior, when decoding a HEIF grid image with strict_decoding=false (the default), a corrupted tile silently fails to decode and the library returns heif_error_Ok with no indication of failure, leading to an uninitialized heap memory information leak. The canvas is allocated via create_clone_image_at_new_size() → plane.alloc() → new (std::nothrow) uint8_t[allocation_size] which does not zero the memory; only the alpha plane is explicitly initialized via fill_plane(), so the Y, Cb, and Cr planes contain whatever was previously at that heap address. The failed tile's region of the canvas is never written. It retains uninitialized heap data that is delivered to the caller as decoded pixel values (4,096 bytes per Y/Cb/Cr plane = 12,288+ bytes total). Any application using libheif to decode grid-based HEIF/AVIF files with default settings is vulnerable: a crafted .heic or .avif file causes 4,096+ bytes of heap memory to appear as pixel values in the decoded image, and the calling application receives heif_error_Ok, so it has no indication the output contains heap garbage. In server-side image processing, an uploaded crafted HEIF decoded and re-encoded (e.g., as PNG/JPEG for thumbnails, CDN, social media) can leak cross-user data such as auth tokens, database results, and other users' image data. This issue has been fixed in version 1.22.0.

AnalysisAI

Heap memory disclosure in strukturag libheif versions 1.21.2 and prior exposes up to 12,288+ bytes of uninitialized heap content - potentially containing auth tokens, database results, or other users' image data - when decoding crafted HEIF or AVIF grid images under the library's default settings. The decode path silently suppresses tile failures while returning heif_error_Ok, so calling applications receive heap garbage as valid pixel values with no error indication. Server-side image pipelines that ingest user-uploaded HEIF/AVIF and re-encode the output (e.g., as PNG or JPEG thumbnails for CDNs or social platforms) are at highest cross-user exposure risk; no public exploit code has been identified at time of analysis and the vulnerability is not listed in CISA KEV.

Technical ContextAI

libheif (cpe:2.3:a:strukturag:libheif:*:*:*:*:*:*:*:*) is an open-source C++ library implementing HEIF and AVIF file format parsing per MPEG/ISO specifications. The vulnerability is rooted in CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) and manifests in the grid image decoding path. Grid images in HEIF/AVIF are composed of independently coded tiles assembled into a canvas; when strict_decoding=false (the library default), tile decode failures are silently suppressed. The code path calls create_clone_image_at_new_size() → plane.alloc() → new (std::nothrow) uint8_t[allocation_size], which does not zero-initialize the heap allocation. Only the alpha channel plane is explicitly zeroed via fill_plane(); the Y, Cb, and Cr luma/chroma planes retain whatever bytes previously occupied those heap addresses. The corrupted tile's canvas region is never overwritten, so those uninitialized bytes - 4,096 bytes per plane across three planes, totaling 12,288+ bytes minimum - are returned to the caller as decoded pixel values alongside a success status.

RemediationAI

The primary fix is upgrading libheif to version 1.22.0 or later, confirmed by the vendor at https://github.com/strukturag/libheif/releases/tag/v1.22.0 and the security advisory at https://github.com/strukturag/libheif/security/advisories/GHSA-4m8r-34pg-rvwc. Applications consuming libheif as a shared system library should update the OS package; those vendoring libheif directly should pin to 1.22.0 and rebuild. Language-binding packages (e.g., Python pyheif, Ruby mini_magick with HEIF support) should await updated releases that bundle the patched version. As a compensating control prior to patching, callers can set strict_decoding=true in the libheif API options, which causes corrupted tile failures to surface as actual errors rather than silently returning garbage output - this prevents the information leak but will reject certain malformed-but-partially-valid real-world HEIF files, potentially breaking compatibility with some user-submitted content. In server-side multi-tenant contexts, running image decode workers in isolated per-request processes (e.g., via fork-per-request or container isolation) limits cross-user heap exposure even if the bug is triggered, at the cost of increased process-spawn overhead.

Vendor StatusVendor

SUSE

Severity: Medium
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise High Performance Computing 15 SP7 Fixed
SUSE Linux Enterprise Module for Desktop Applications 15 SP7 Fixed
SUSE Linux Enterprise Module for Package Hub 15 SP7 Fixed
SUSE Linux Enterprise Server 15 SP7 Fixed

Share

EUVD-2026-30980 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy