CVE-2026-73638
Niskie ryzyko· EPSS 7%Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 7 - wyżej niż 7% wszystkich znanych CVE
Streszczenie
Imager w wersjach od 0.45_02 przed 1.035 dla Perla odczytuje dane poza blokiem EXIF poprzez niekontrolowane przesunięcia początkowe w funkcji tiff_load_ifd. Funkcja tiff_load_ifd() waliduje dane wpisu IFD, sprawdzając, czy suma entry->offset + entry->size mieści się w bloku EXIF, ale nigdy nie sprawdza samego przesunięcia początkowego. Gdy suma nie jest rzeczywistym końcem danych, sprawdzenie przechodzi, mimo że wpis zaczyna się poza blokiem. Do wersji 1.032 pole entry->offset jest zwykłym int, więc na typowych implementacjach dopełnienia do dwóch offset z ustawionym najstarszym bitem staje się ujemny i suma może wrócić do wnętrza bloku. Od wersji 1.033 pole jest typu size_t, a dodawanie zawija się tylko tam, gdzie size_t ma 32 bity. Własne przesunięcie początkowe IFD jest sprawdzane w ten sam sposób i zawija się tam, gdzie unsigned long ma 32 bity, co obejmuje 64-bitowy Windows. Każdy wywołujący Imager->read() na dostarczonym przez atakującego obrazie może otrzymać tagi EXIF zawierające bajty spoza bloku lub spowodować awarię procesu.
Ocena ryzyka
Atakujący może dostarczyć spreparowany obraz, który po odczytaniu przez Imager->read() ujawnia dane spoza bloku EXIF lub powoduje awarię procesu, prowadząc do odmowy usługi lub wycieku informacji. Ryzyko dotyczy szczególnie systemów 32-bitowych i 64-bitowego Windows.
Rekomendacja
Zaktualizuj Imager do wersji 1.035 lub nowszej. Unikaj odczytu niezaufanych obrazów bez uprzedniej walidacji.
Inne podatności w Imager
Zobacz wszystkie- CVE-2026-93018Nieznane
Wersje Imager dla Perla przed 1.036 ujawniają niezainicjalizowaną pamięć sterty podczas odczytu obrazu paletowego z indeksami pikseli wykraczającymi poza mapę kolorów w funkcjach i_gpix_p i i_glin_p. Paleta jest alokowana bez inicjalizacji, a czytnik TGA zapisuje indeksy pikseli bez sprawdzania ich względem mapy kolorów, co pozwala odczytać lub wyświetlić zawartość wcześniejszej pamięci sterty.
- CVE-2026-93019Krytyczne
Wersje Imager dla Perla przed 1.036 kończą proces podczas odczytu pliku TGA z długością mapy kolorów wynoszącą 32768 lub więcej w funkcji tga_palette_read. Długość jest rozpakowywana do typu signed short, przez co wartość 32768 lub większa staje się ujemna, a następnie rzutowana na size_t, co powoduje żądanie alokacji o rozmiarze bliskim SIZE_MAX. Alokacja kończy się niepowodzeniem, a alokator Imager wywołuje exit(3).
- CVE-2026-14454Krytyczne
Podatność w bibliotece Imager dla Perla przed wersją 1.033 polega na błędnym traktowaniu liczników wpisów EXIF IFD jako liczb ze znakiem, co może prowadzić do próby alokacji ogromnego bloku pamięci i awarii procesu. Atakujący może wykorzystać to, tworząc obraz z odpowiednio spreparowanymi danymi EXIF, aby przerwać działanie procesu roboczego.
- CVE-2026-19082Wysokie
Imager w wersjach od 0.45_02 do 1.034 dla Perla może ujawnić sąsiednie bajty sterty poprzez odczyt strlen() z zerowej liczby wpisów ASCII EXIF w copy_string_tags. Atakujący może dostarczyć obraz z takim wpisem, co prowadzi do wycieku danych ze sterty do znacznika exif_*.
- CVE-2026-13705Wysokie
W bibliotece Imager dla Perla przed wersją 1.032 występuje podatność polegająca na odczycie poza dozwolonym obszarem sterty (heap out-of-bounds read) w module Imager::File::SGI. Problem dotyczy funkcji read_rgb_16_rle, która nieprawidłowo sprawdza liczbę pikseli w przebiegu RLE, co prowadzi do odczytu poza buforem. Atakujący może wykorzystać tę podatność, dostarczając spreparowany obraz SGI, co może spowodować awarię procesu.
Oryginalny opis (angielski, źródło NVD)
Imager versions from 0.45_02 before 1.035 for Perl read outside the EXIF block via unchecked start offsets in tiff_load_ifd. tiff_load_ifd() validates an IFD entry's data by checking that `entry->offset + entry->size` stays within the EXIF block, and never checks the start offset itself. Where that sum is not the real end of the data, the check passes with the entry starting outside the block. Through 1.032 `entry->offset` is a plain int, so on the usual two's-complement implementations an offset with the high bit set converts to negative and the sum can land back inside the block. From 1.033 the field is a size_t and the addition wraps only where size_t is 32 bits. The IFD's own start offset is checked the same way and wraps where unsigned long is 32 bits, which includes 64-bit Windows. Any caller of Imager->read() on an attacker-supplied image may receive EXIF tags holding bytes from outside the block, or crash the process.