CVE-2026-32814

What it actually does

This is an information disclosure flaw in libheif's handling of HEIF/AVIF grid images. When strict_decoding=false, which is the default, a crafted grid image can cause one tile decode operation to fail silently while libheif still returns heif_error_Ok to the caller. The output canvas is heap-allocated without zero initialization, and the failed tile region is never overwritten for the Y, Cb, and Cr planes. As a result, previously used heap memory can be exposed as pixel data in the decoded image, with approximately 12 KB or more of memory potentially leaked per crafted decode depending on image layout and processing behavior.

Why it matters to the business

Applications that accept or process user-supplied HEIF or AVIF images may unintentionally disclose sensitive memory contents through generated thumbnails, previews, transformed images, or CDN/social-media style re-encodes. In multi-user server-side image processing, leaked memory could include fragments of other users' image data, application responses, tokens, or other transient data previously present in the image processing worker's heap. The CVSS confidentiality impact is high, but current public exploitation signals are low: EPSS is 0.00311 with no 30-day increase, it is not listed in CISA KEV, and no mature exploit is reported. Organizations should still prioritize remediation where HEIF/AVIF uploads are processed at scale or in shared worker processes.

How an attack unfolds

An attacker creates a malformed HEIF or AVIF grid image in which at least one tile fails to decode while the overall decode operation is treated as successful under libheif's default non-strict decoding mode. The attacker submits this file to an application that uses vulnerable libheif versions to decode images, such as an upload pipeline, thumbnail generator, media conversion service, content moderation system, or preview renderer. During decoding, libheif allocates the output image canvas but does not zero the Y, Cb, and Cr planes. The corrupted tile's region is left unwritten, retaining whatever heap data previously occupied that memory. Because libheif returns success, the application continues normal processing and may re-encode the decoded image to PNG, JPEG, WebP, or another format. The attacker then retrieves the resulting transformed image and inspects the affected pixel region to recover leaked heap bytes. Repeating the process may expose different memory fragments depending on allocator behavior, worker reuse, and surrounding workload.

How to fix it

Upgrade libheif to version 1.22.0 or later wherever it is present, including direct installations, statically linked builds, containers, language bindings, operating-system packages, media-processing appliances, and applications that bundle their own copy of libheif. If immediate upgrade is not possible, configure decoders to use strict decoding where supported, reject or quarantine HEIF/AVIF grid images from untrusted sources, disable HEIF/AVIF upload support temporarily for high-risk paths, or route image processing through isolated short-lived worker processes. Defense-in-depth mitigations include zero-initializing image buffers before use, treating partial tile decode failures as hard failures, stripping intermediate outputs, and ensuring media conversion services do not share long-lived memory across security boundaries.

How to confirm the fix worked

Confirm that all deployed libheif instances report version 1.22.0 or later, including versions embedded inside applications, containers, serverless images, desktop clients, and third-party media tooling. Use package manager queries, software composition analysis, container image scanning, and binary inspection where applicable. Validate application behavior by processing a known malformed HEIF/AVIF grid test file in a non-production environment: a fixed or mitigated implementation should fail closed, reject the image, or produce fully initialized output rather than returning success with uninitialized tile contents. Also verify that HEIF/AVIF processing paths use strict decoding or equivalent hard-failure behavior and that generated outputs do not contain deterministic regions sourced from prior heap contents.

Typical attack path

1. Identify an application or service that accepts HEIF or AVIF image uploads or fetches remote HEIF/AVIF media for processing.
2. Craft a HEIF/AVIF grid image with a corrupted tile that fails to decode while the overall image decode still succeeds under libheif's default strict_decoding=false behavior.
3. Submit the crafted image to a vulnerable processing path such as thumbnailing, preview generation, media transcoding, or content ingestion.
4. Allow the application to decode and re-encode the image, preserving the uninitialized tile region as visible or recoverable pixel data.
5. Download or view the processed output image returned by the application.
6. Extract and analyze pixel values from the affected region to recover leaked heap memory fragments.
7. Repeat submissions to increase the chance of capturing useful sensitive data from reused image-processing worker memory.

How to detect it

Retrospective detection is difficult because successful exploitation produces normal-looking decode success paths and may not generate libheif errors. Focus on image-ingestion and media-processing telemetry. Review upload, fetch, and conversion logs for HEIF or AVIF files processed by vulnerable versions, especially repeated submissions from the same source followed by downloads of generated thumbnails or converted outputs. Look for malformed or unusually structured HEIF/AVIF grid images, conversion jobs that succeeded despite downstream visual corruption, and outputs with rectangular tile-sized regions of high-entropy or non-image-like pixel data. Preserve original uploads and generated derivatives for forensic review. If available, correlate web access logs, object storage access logs, media worker job logs, CDN logs, and application audit trails to identify actors who uploaded HEIF/AVIF files and immediately retrieved processed variants. Memory disclosure contents are workload-dependent, so absence of error logs is not evidence of non-exploitation.

What your security team should do

• Inventory all services, applications, containers, and third-party products that decode HEIF or AVIF images using libheif.
• Prioritize upgrades to libheif 1.22.0 or later for internet-facing upload, thumbnailing, CDN, messaging, social media, document preview, and media conversion workflows.
• Temporarily disable HEIF/AVIF processing or reject HEIF/AVIF grid images from untrusted users where patching cannot be completed quickly.
• Ensure image-processing workers are isolated by tenant or trust boundary where feasible, and prefer short-lived worker processes for untrusted media.
• Add regression tests using malformed grid images to confirm decoders fail closed and do not emit partially initialized output.
• Review generated thumbnails or converted images from suspicious HEIF/AVIF uploads for anomalous blocks that may contain non-image data.
• Monitor dependency and base-image updates because libheif is commonly pulled in indirectly through image processing frameworks, desktop libraries, and media conversion tools.