CVE-2026-84451

libheif to dekoder i enkoder formatów HEIF oraz AVIF. W wersjach od 1.19.0 do 1.23.3 spreparowany element obrazu zawierający właściwość clap oraz szerokość lub wysokość ispe większą niż INT32_MAX + 1 może doprowadzić do obliczeń przycinania przez heif_image_handle_get_image_tiling(). Funkcja Box_clap::left_rounded() lub Box_clap::top_rounded() przekazuje wymiar obrazu minus jeden do Fraction::Fraction(), którego konstruktor uint32_t używa asercji jako walidacji danych wejściowych, powodując przerwanie kompilacji z włączonymi asercjami. Wersje produkcyjne mogą obliczyć nieprawidłową geometrię przycinania, a API kafelkowania zwraca wymiary odrzucane przez normalne limity bezpieczeństwa dekodowania. Problem naprawiono w wersji 1.23.3.

libheif, dekoder i enkoder formatów HEIF i AVIF, w wersjach przed 1.19.6 posiada przepełnienie licznika szerokości w funkcji Op_RGB24_32_to_YCbCr::convert_colorspace(), które może wystąpić dla bardzo dużych obrazów RGB. Powoduje to obliczenie nieprawidłowego wskaźnika wejściowego i odczyt poza zaalokowanym buforem podczas konwersji RGB do YCbCr, co może doprowadzić do awarii procesu kodowania.

libheif to dekoder i enkoder formatów HEIF oraz AVIF. Przed wersją 1.23.2 publiczna funkcja heif_region_item_add_region_inline_mask_data() w libheif/api/libheif/heif_regions.cc przyjmuje mask_data_len bez weryfikacji, czy jest równa liczbie bajtów wymaganej przez width i height. Późniejsze wywołanie heif_region_get_mask_image() wylicza długość odczytu z geometrii regionu, więc zbyt mały bufor powoduje odczyt poza alokacją sterty i skopiowanie sąsiednich bajtów do zwróconego obrazu maski monochromatycznej. Może to ujawnić dane ze sterty lub zawiesić aplikację, która tworzy metadane regionu przez API zapisu; ścieżka parsowania plików nie jest podatna, ponieważ waliduje kanoniczny rozmiar maski. Problem naprawiono w wersji 1.23.2.

libheif to dekoder i koder formatów HEIF i AVIF. W wersji 1.23.1 i wcześniejszych spreparowane grafy referencji grid, iovl i iden mogą wielokrotnie dekodować ten sam obraz bazowy, ponieważ processed_ids jest kopiowane dla każdej gałęzi, a ImageItem::decode_image() nie ma wspólnego budżetu operacji. Podatność naprawiono w wersji 1.23.2.

libheif to dekoder i koder formatów HEIF i AVIF. Przed wersją 1.23.2 spreparowane dane czasowania sekwencji HEIF i listy edycji mogą sprawić, że Track::init_sample_timing_table() obliczy logiczną wartość m_num_output_samples przekraczającą liczniki uint32_t używane przez Track_Visual::decode_next_image_sample() i Track::get_next_sample_raw_data(). Powstałe porównanie nigdy nie osiąga zbyt dużej liczby wyjściowej, powodując nieskończone pętle dekodowania lub próbkowania surowego i omijając max_sequence_frames. Ta sama ścieżka sekwencji wielokrotnie wywołuje Box_stts::get_sample_duration() i alokuje Chunk::m_sample_ranges oraz Track::m_presentation_timeline poza rozliczaniem MemoryHandle, co pozwala na poważne wyczerpanie CPU i pamięci z małego pliku. Problem naprawiono w wersji 1.23.2.

libheif to dekoder i koder formatów HEIF i AVIF. Przed wersją 1.23.2, gdy włączony jest WITH_UNCOMPRESSED_CODEC, heif_context_add_image_tile() akceptuje niezależnie skonstruowany kafelek, którego wymiary płaszczyzny komponentów nie pasują do geometrii kafelka ustalonej przez obraz prototypowy. ImageItem_uncompressed::add_image_tile() przekazuje ten kafelek bezpośrednio do unc_encoder::encode_tile(), który nie miał bramki check_component_sizes() i ustala rozmiar wyjścia na podstawie skonfigurowanej geometrii kafelka, kopiując rzeczywiste wymiary płaszczyzny komponentów kafelka. Zbyt duża płaszczyzna komponentów może zatem sprawić, że unc_encoder_component_interleave::encode_tile() skopiuje dane kontrolowane przez atakującego poza bufor wyjściowy na stercie. Problem naprawiono w wersji 1.23.2.

libheif to dekoder i koder formatów HEIF i AVIF. Od wersji 1.19.0 do 1.23.2 spreparowane metadane MIME HEIF lub AVIF oraz dane obrazu unci mogą powodować, że decompress_brotli() i do_inflate() zwiększają skumulowane wyjście bez skutecznego limitu rozmiaru lub rozliczania MemoryHandle. Ścieżka brotli nie ma ograniczenia wyjścia, a ścieżka zlib sprawdza tylko mały bufor tymczasowy w gałęzi, do której prawidłowe strumienie nie docierają, a nakładające się jednostki icef mogą wielokrotnie dekompresować ten sam ładunek. HeifContext::interpret_heif_file_images() przetwarza wiele skompresowanych elementów metadanych podczas otwierania pliku, co pozwala małemu plikowi zużyć nieograniczoną pamięć i zatrzymać proces. Problem naprawiono w wersji 1.23.2.

Wykryto i naprawiono kilka podatności (dwie o krytycznym poziomie CVSSv3) w zależności libheif. Mogą one prowadzić do zdalnego wykonania kodu (RCE) na systemach Linux bazujących na glibc pod pewnymi warunkami.

libheif w wersjach od 1.22.0 do 1.23.2 ma podatność na przepełnienie sterty (heap out-of-bounds write). Specjalnie spreparowany plik HEIF/HEIC/AVIF z zagnieżdżonymi referencjami iden i auxl powoduje dodanie duplikatów kanałów Alpha z różną głębią bitową, a funkcja scale_nearest_neighbor() alokuje mniejszy bufor niż potrzeba, prowadząc do zapisu poza pamięć.

Podatność w bibliotece libheif używanej przez sharp (którą Next.js używa do optymalizacji obrazów) może prowadzić do zdalnego wykonania kodu podczas optymalizacji plików AVIF. Do czasu rozpowszechnienia poprawki optymalizacja plików AVIF jest wyłączona.