You are viewing this page in an unauthorized frame window.
This is a potential security issue, you are being redirected to
https://nvd.nist.gov
An official website of the United States government
Official websites use .gov
A .gov website belongs to an official government organization in the United States.
Secure .gov websites use HTTPS
A lock () or https:// means you've safely connected to the .gov website. Share sensitive information only on official, secure websites.
This CVE record is not being prioritized for NVD enrichment efforts due to resource or other concerns.
Description
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.
Metrics
NVD enrichment efforts reference publicly available information to associate
vector strings. CVSS information contributed by other sources is also
displayed.
By selecting these links, you will be leaving NIST webspace.
We have provided these links to other web sites because they
may have information that would be of interest to you. No
inferences should be drawn on account of other sites being
referenced, or not, from this page. There may be other web
sites that are more appropriate for your purpose. NIST does
not necessarily endorse the views expressed, or concur with
the facts presented on these sites. Further, NIST does not
endorse any commercial products that may be mentioned on
these sites. Please address comments about this page to [email protected].
Title: libheif de strukturag, Description: libheif es un decodificador y codificador de formato de archivo HEIF y AVIF. En las versiones 1.21.2 y anteriores, al decodificar una imagen de cuadrícula HEIF con strict_decoding=false (el valor predeterminado), un mosaico corrupto falla silenciosamente al decodificarse y la biblioteca devuelve heif_error_Ok sin ninguna indicación de fallo, lo que lleva a una fuga de información de memoria de pila no inicializada. El lienzo se asigna a través de create_clone_image_at_new_size() ? plane.alloc() ? new (std::nothrow) uint8_t[allocation_size] que no pone a cero la memoria; solo el plano alfa se inicializa explícitamente a través de fill_plane(), por lo que los planos Y, Cb y Cr contienen lo que estuviera previamente en esa dirección de pila. La región del lienzo correspondiente al mosaico fallido nunca se escribe. Retiene datos de pila no inicializados que se entregan al llamador como valores de píxel decodificados (4.096 bytes por plano Y/Cb/Cr = 12.288+ bytes en total). Cualquier aplicación que utilice libheif para decodificar archivos HEIF/AVIF basados en cuadrícula con la configuración predeterminada es vulnerable: un archivo .heic o .avif manipulado hace que 4.096+ bytes de memoria de pila aparezcan como valores de píxel en la imagen decodificada, y la aplicación que llama recibe heif_error_Ok, por lo que no tiene ninguna indicación de que la salida contenga basura de pila. En el procesamiento de imágenes del lado del servidor, un HEIF manipulado subido, decodificado y recodificado (por ejemplo, como PNG/JPEG para miniaturas, CDN, redes sociales) puede filtrar datos entre usuarios, como tokens de autenticación, resultados de base de datos y datos de imagen de otros usuarios. Este problema ha sido solucionado en la versión 1.22.0.
New CVE Received from GitHub, Inc.5/19/2026 5:16:42 PM
Action
Type
Old Value
New Value
Added
Description
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.