CVE-2026-106110

W bibliotece ImageSharp w wersjach od 3.0.0 do 4.1.1 dekodowanie kafelkowych plików TIFF powoduje niezgodność rozmiaru bufora: bufor docelowy jest alokowany na podstawie TileWidth, a dekompresory T4, T6 i Modified Huffman używają pełnej szerokości ramki. Gdy TileWidth jest mniejsze niż ImageWidth, dane faksu o szerokości ramki są zapisywane do bufora o szerokości kafla, co prowadzi do zapisów poza zakresem i uszkodzenia sterty. Podatność została naprawiona w wersji 4.1.1.

W bibliotece ImageSharp w wersjach od 3.0.0 do 4.1.1 dekodowanie paskowego pliku TIFF z kompresją CCITT Group 3 lub Modified Huffman może przekazywać rozszerzone przez atakującego ciągi do BitWriterUtils.WriteBits bez uprzedniego sprawdzenia szerokości wiersza. T4TiffCompression.WritePixelRun może gromadzić zbyt duże ciągi kodów makeup, a ModifiedHuffmanTiffCompression.Decompress sprawdza szerokość dopiero po zapisie. Niekontrolowane zapisy mogą przepełnić bufor paska, uszkodzić pamięć sterty i zakończyć proces. Podatność została naprawiona w wersji 4.1.1.

W bibliotece ImageSharp od wersji 2.0.0 do 4.1.2 funkcja ExifReader.ReadValues64 ufa 64-bitowej liczbie wpisów IFD w formacie BigTIFF i iteruje raz na każdy zadeklarowany wpis. Gdy pozostało mniej niż 20 bajtów, funkcja ReadValue64 zwraca bez przesuwania strumienia lub kończenia pętli, co pozwala małemu uszkodzonemu plikowi BigTIFF utrzymać wątek dekodera przez czas kontrolowany przez atakującego. Problem naprawiono w wersji 4.1.2.

W bibliotece ImageSharp w wersjach od 2.1.0 do 4.1.2 koder TIFF CCITT Group 4 alokuje bufor o rozmiarze Width razy rowsPerStrip, mimo że T6BitCompressor.CompressStrip może wygenerować dane wiersza i dwa 12-bitowe kody końca bloku faksu przekraczające tę pojemność. TiffCcittCompressor.WriteCode wykonuje niezaznaczone zapisy, a przepływ dekodowania i ponownego kodowania może odziedziczyć TiffCompression.CcittGroup4Fax i metadane jednobitowe z danych wejściowych atakującego. Powstałe zapisy poza zakresem mogą uszkodzić pamięć i zakończyć proces. Podatność została naprawiona w wersji 4.1.2.

W bibliotece ImageSharp od wersji 1.0.0-beta0001 do 4.1.2 parsowanie CLUT w profilach ICC oblicza rozmiary alokacji na podstawie zadeklarowanych przez atakującego wymiarów kanałów i siatki, zanim potwierdzi, że profil zawiera te wartości. Funkcja IccDataReader.ReadClutF32 może żądać dużej tablicy float, a wcześniejsze ścieżki parsowania IccProfile.Entries mogą przydzielić dużą reprezentację z krótkiego profilu. W wersji 4 automatyczna konwersja obrazu dociera do parsera, gdy DecoderOptions.ColorProfileHandling jest ustawione na Convert; domyślny tryb Preserve unika tej ścieżki. Problem naprawiono w wersji 4.1.2.

W bibliotece ImageSharp w wersjach od 2.0.0 do 4.1.2 dekodowanie dostarczonego przez atakującego 32-bitowego pliku TIFF zmiennoprzecinkowego jako Image<HalfVector4> i zastosowanie HistogramEqualization może wygenerować nieskończoną lub poza zakresem luminancję w ColorNumerics.GetBT709Luminance. GrayscaleLevelsRowOperation.Invoke używa wynikowej wartości jako niezaznaczonego przesunięcia histogramu, powodując niebezpieczny dostęp poza zakresem i zakończenie procesu. Adaptive Histogram Equalization i AutoLevel nie są objęte tym raportem. Podatność została naprawiona w wersji 4.1.2.

W bibliotece ImageSharp w wersjach od 4.0.0 do 4.1.2 konwersja ICC LUT16 akceptuje więcej niż cztery kanały wyjściowe, mimo że ClutCalculator.Calculate i LutEntryCalculator.CalculateLut przechowują wartości pośrednie i wyjściowe w Vector4. Gdy DecoderOptions.ColorProfileHandling jest ustawione na Convert, złośliwy osadzony profil może spowodować zapis jednego float na zadeklarowany kanał poza czteroelementowym miejscem docelowym. Może to uszkodzić pamięć i zakończyć proces; domyślny tryb Preserve nie uruchamia konwersji ICC. Podatność została naprawiona w wersji 4.1.2.

W bibliotece ImageSharp od wersji 4.0.0 do 4.1.2 funkcja ExrBaseDecompressor.UndoZipCompression akceptuje niepusty wynik dekompresji ZIP lub ZIPS, który jest krótszy niż wymagany rozmiar bloku EXR. ZipExrCompression.Decompress rekonstruuje zwrócony prefiks, podczas gdy ExrDecoderCore przetwarza pełny oczekiwany blok z bufora uzyskanego przez Configuration.Default, co pozwala na pojawienie się bajtów z wcześniej zakończonej operacji ImageSharp w zdekodowanych pikselach. Aplikacje, które udostępniają piksele lub dane wyjściowe z późniejszego dekodowania EXR, mogą ujawnić dane obrazu lokalnego procesu. Problem naprawiono w wersji 4.1.2.