CVE-2026-59189
WysokieCVSS 7.1Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 16 - wyżej niż 16% wszystkich znanych CVE
Streszczenie
W bibliotece OpenEXRUtil (część OpenEXR) w wersjach 3.3.0 do 3.3.12 oraz 3.4.0 do 3.4.12, udokumentowane API TypedDeepImageChannel<T>::row() może zwracać wskaźnik poza zakresem, gdy obraz głęboki ma niezerowe pochodzenie okna danych (dataWindow origin). Prowadzi to do odczytu poza stertą i awarii, z potencjalnym ujawnieniem informacji przy kontrolowanym układzie sterty. Problem naprawiono w wersjach 3.3.13 i 3.4.13.
Ocena ryzyka
Podatność może prowadzić do awarii aplikacji (DoS) oraz potencjalnego wycieku danych, co może być wykorzystane do dalszych ataków.
Rekomendacja
Zaleca się aktualizację OpenEXR do wersji 3.3.13 lub 3.4.13 (lub nowszej) w celu wyeliminowania podatności.
Inne podatności w OpenEXR
Zobacz wszystkie- CVE-2017-12596Wysokie
W OpenEXR 2.2.0, specjalnie przygotowany obraz powoduje nadmierne odczytywanie bufora w funkcji hufDecode w pliku IlmImf/ImfHuf.cpp podczas wykonywania exrmaketiled. Może to prowadzić do odmowy usługi lub innych nieokreślonych skutków.
- CVE-2017-9115Wysokie
W OpenEXR 2.2.0 występuje nieprawidłowe zapisanie danych o rozmiarze 2 w funkcji operatora = w pliku half.h, co może prowadzić do awarii aplikacji lub wykonania dowolnego kodu.
- CVE-2017-9113Wysokie
W OpenEXR 2.2.0 występuje nieprawidłowe zapisanie danych o rozmiarze 1 w funkcji bufferedReadPixels w pliku ImfInputFile.cpp, co może prowadzić do awarii aplikacji lub wykonania dowolnego kodu.
- CVE-2017-9111Wysokie
W OpenEXR 2.2.0 występuje nieprawidłowe zapisanie danych o rozmiarze 8 w funkcji storeSSE w pliku ImfOptimizedPixelReading.h, co może prowadzić do awarii aplikacji lub wykonania dowolnego kodu.
- CVE-2026-42217Krytyczne
OpenEXR w wersjach od 3.0.0 do przed 3.2.9, 3.3.0 do przed 3.3.11 oraz 3.4.0 do przed 3.4.11 ma problem z funkcją readVariableLengthInteger(), która dekoduje zmienną długość liczby całkowitej z niezaufanego wejścia EXR bez ograniczenia liczby przesunięć. Po wystarczającej liczbie bajtów kontynuacji, kod wykonuje przesunięcie w lewo o 70 na 64-bitowej wartości, co prowadzi do nieokreślonego zachowania.
- CVE-2026-42216Krytyczne
W bibliotece OpenEXR w wersjach od 3.0.0 do 3.2.9, od 3.3.0 do 3.3.11 oraz od 3.4.0 do 3.4.11 wykryto podatność w funkcji IDManifest::init(). Podczas rekonstrukcji ciągów znaków z reprezentacji skompresowanej prefiksowo, kod odczytuje bajty bez sprawdzenia, czy bieżący ciąg ma co najmniej dwa bajty, co może prowadzić do odczytu poza zakresem.
- CVE-2026-68515Wysokie
OpenEXR przed wersjami 3.2.11, 3.3.13 i 3.4.14 zawiera podatność w narzędziu exrmultiview, które może zapisywać poza stertą podczas łączenia dwóch dostarczonych przez atakującego, indywidualnie poprawnych plików EXR, gdy unia dataWindow nie jest wyrównana do próbkowania kanałów jednego widoku. Prowadzi to do zapisu poza granicami sterty.
- CVE-2026-68514Średnie
PyOpenEXR w wersjach 3.3.0-3.3.12 i 3.4.0-3.4.13 ma podatność na zapis poza stertą podczas odczytu spreparowanego pliku EXR z głębokimi scanline'ami. Specjalnie skonstruowany plik z kanałem 'left' i warstwowymi kanałami RGB może spowodować przepełnienie bufora i awarię.
- CVE-2026-68513Wysokie
OpenEXR w wersjach 3.3.0 do 3.3.12 i 3.4.0 do 3.4.13 zawiera przepełnienie bufora sterty w PyOpenEXR, wywoływane przez kolizję nazw kanałów między dosłownymi a prefiksowanymi kanałami RGB. Specjalnie spreparowany plik EXR może spowodować zapis poza granicami tablicy NumPy podczas dekodowania pikseli.
- CVE-2026-59981Wysokie
OpenEXR w wersjach do 3.2.10, 3.3.0 do 3.3.12 i 3.4.0 do 3.4.13 zawiera podatność w bibliotece OpenEXRUtil, która zwraca wskaźnik poza zakresem z API SampleCountChannel::row() dla obrazów głębokich z niezerowym początkiem dataWindow. Może to prowadzić do odczytu poza zakresem, co może spowodować awarię procesu lub ujawnienie danych z pamięci.
Oryginalny opis (angielski, źródło NVD)
OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. In OpenEXRUtil versions 3.3.0 through 3.3.12 and 3.4.0 through 3.4.12, the documented TypedDeepImageChannel<T>::row() API can return an out-of-bounds pointer when a deep image has a non-zero dataWindow origin, resulting in a heap out-of-bounds read and crash, with potential information disclosure under a controlled heap layout. The flaw arises because ImfDeepImageChannel uses two conflicting coordinate models: at(x, y) uses absolute coordinates (with _base offset by dataWindow.min), while row(r) is documented as 0-based logical access. For a non-zero dataWindow.min, row(0) therefore points outside the _sampleListPointers allocation instead of at the first logical row. This issue is fixed in versions 3.3.13 and 3.4.13.