Katalog podatności CVE

W WeGIA przed wersją 3.8.7 występuje podatność stored DOM cross-site scripting w pliku web/html/memorando/listar_despachos.php wynikająca z niebezpiecznej obsługi pola texto. FILTER_SANITIZE_SPECIAL_CHARS jest stosowany podczas zapisu, ale html_entity_decode() później dekoduje zawartość, a jQuery .html() wstawia wynik do DOM.

Na systemie Linux uwierzytelniony użytkownik Nessus z niskimi uprawnieniami i prawem do tworzenia skanów mógł odczytać dowolne pliki tekstowe na hoście skanera z uprawnieniami procesu nessusd, uruchamiając własny audyt zgodności Unix wymierzony w sam skaner.

Fiber to framework webowy w Go inspirowany Express. W wersjach od 2.52.1 do 2.52.3 mechanizm dopasowywania wildcard validateDomain w middleware CORS (middleware/cors/utils.go) usuwa schemat i sprawdza jedynie sufiks hosta bez wymagania granicy kropki. Aplikacja skonfigurowana z wartością AllowOrigins zawierającą wildcard subdomeny i włączonym AllowCredentials może odzwierciedlić niepowiązane pochodzenie kontrolowane przez atakującego, którego host jedynie kończy się skonfigurowaną domeną bazową.

joserfc to biblioteka Pythona implementująca standardy JOSE. Przed wersją 1.7.6 deserializacja kompaktowego JWS wywołuje bytes.split() przed egzekwowaniem istniejących limitów rozmiaru segmentów. Gdy kontrolowane przez atakującego bajty trafiają do deserialize_compact(), split tworzy kopie nagłówka, ładunku i podpisu przed odrzuceniem przez ExceededSizeError, powodując dodatkową alokację proporcjonalną do dostarczonego tokenu.

MariaDB Connector/J w wersjach od 3.0.0 do 3.3.7, 3.4.5 i 3.5.11 zakładał, że bajty wyników są w UTF-8, ale kontrolował tylko zmiany character_set_client. Nie odrzucał zmian character_set_results na inne niż UTF-8 i polegał na globalnej konfiguracji session_track_system_variables serwera do raportowania zmian zestawu znaków. Złośliwy lub przejęty serwer albo atakujący typu man-in-the-middle mógł wyłączyć śledzenie lub zmienić zestaw znaków wyników, przez co ciągi znaków w aplikacji różniły się od zwróconych bajtów, potencjalnie obchodząc walidację lub escapowanie po stronie aplikacji zależne od zdekodowanych wartości. Naprawiono w wersjach 3.3.7, 3.4.5 i 3.5.11.

MariaDB Connector/J w wersjach od 3.0.0 do 3.3.7, 3.4.5 i 3.5.10 zawiera błąd w metodach ReadableByteBuf.readLength() i ReadableByteBuf.readIntLengthEncodedNotNull(), które zawężały 8-bajtową liczbę całkowitą bez znaku (length-encoded integer) do Java int bez sprawdzenia, czy wartość mieści się w zakresie nieujemnej liczby całkowitej. Wartości powyżej Integer.MAX_VALUE mogły zawinąć się do ujemnej lub niepowiązanej długości używanej przez dalsze ścieżki alokacji i odczytu. Złośliwy lub przejęty serwer albo atakujący typu man-in-the-middle mógł wywołać NegativeArraySizeException, błędy out-of-bounds lub nadmierną alokację w obsłudze połączenia klienta. Naprawiono w wersjach 3.3.7, 3.4.5 i 3.5.10.

MariaDB Connector/J w wersjach od 3.0.0 do 3.3.7 i 3.4.5 podczas uwierzytelniania caching_sha2_password traktował odpowiedź authentication-more-data jako tablicę bajtów z kodowaniem długości, alokował pamięć na podstawie długości zadeklarowanej przez serwer i uzyskiwał dostęp do authResult[0] bez zapewnienia istnienia bajtu. Złośliwy lub przejęty serwer albo atakujący typu man-in-the-middle mógł zadeklarować bardzo dużą długość lub wysłać pustą odpowiedź przed przesłaniem hasła. Zniekształcony pakiet mógł spowodować nadmierną alokację lub niekontrolowany ArrayIndexOutOfBoundsException wydostający się z DriverManager.getConnection(). Naprawiono w wersjach 3.3.7 i 3.4.5.

MariaDB Connector/J w wersjach od 3.0.0 do 3.3.7, 3.4.5 i 3.5.11 dekodery bloków stanu sesji pakietu OK, pakietów definicji kolumn, danych wierszy tekstowych lub binarnych używały długości zadeklarowanych przez serwer bez potwierdzenia, że żądane bajty pozostają w buforze odbioru. Dekodery mogły pozycjonować odczyty, tworzyć podbufory lub dekodować ciągi poza granicą pakietu. Złośliwy lub przejęty serwer albo atakujący typu man-in-the-middle mógł wywołać niekontrolowane wyjątki ArrayIndexOutOfBoundsException lub IllegalArgumentException w wywołaniach JDBC i przerwać obsługę połączenia. Naprawiono w wersjach 3.3.7, 3.4.5 i 3.5.11.

MariaDB Connector/J w wersjach od 3.0.0 do 3.3.7, 3.4.5 i 3.5.11, gdy wynegocjowano CLIENT_SESSION_TRACK, ścieżki OkPacket.parse() i OkPacket.parseWithInfo() alokowały tablice bajtów na podstawie długości zadeklarowanych przez serwer dla pola info pakietu OK oraz nazw i wartości zmiennych stanu sesji, zanim potwierdzono, że bajty pozostają w pakiecie. Złośliwy lub przejęty serwer albo atakujący typu man-in-the-middle mógł wysłać mały pakiet OK deklarujący znacznie większą długość i wielokrotnie wymuszać alokacje sterty kontrolowane przez atakującego, zanim kolejna kopia zakończyła się niepowodzeniem. Mogło to powodować presję na garbage collector lub OutOfMemoryError w aplikacji klienckiej. Naprawiono w wersjach 3.3.7, 3.4.5 i 3.5.11.

MariaDB Connector/J w wersjach od 3.0.0 do 3.3.7, 3.4.5 i 3.5.11 używał w metodzie ClientMessage.validateLocalFileName() wyrażenia regularnego, które mogło dopasować tekst LOAD DATA LOCAL INFILE wewnątrz cytowanych identyfikatorów, literałów ciągów lub komentarzy, zamiast wymagać rzeczywistej instrukcji. Złośliwy lub przejęty serwer albo atakujący typu man-in-the-middle mógł zwrócić spreparowane identyfikatory bazy danych lub tabeli, które łącznik wykorzystał w zapytaniach metadanych lub aktualizowalnych wyników, a następnie odpowiedzieć żądaniem LOCAL INFILE dla pliku klienta. Przy włączonym allowLocalInfile powodowało to przesyłanie przez łącznik dowolnego czytelnego pliku hosta klienta wskazanego przez spreparowany tekst, w tym przez ścieżki DatabaseMetaData.getImportedKeys(), DatabaseMetaData.getExportedKeys() lub ResultSet.updateRow(). Naprawiono w wersjach 3.3.7, 3.4.5 i 3.5.11.

pypdf przed wersją 6.21.3 może zużywać nadmierną pamięć podczas otwierania spreparowanego pliku PDF zawierającego strumienie cross-reference deklarujące bardzo duże liczby wpisów. Wysoce kompresowalne strumienie i łańcuchy /Prev mogą zwielokrotnić liczbę parsowanych wpisów, a ujemne wartości /Index omijają istniejące ograniczenie.

pypdf przed wersją 6.21.3 może zużywać nadmierny czas i pamięć, gdy aplikacja odczytuje liczbę stron spreparowanego zaszyfrowanego pliku PDF, którego drzewo stron deklaruje sfałszowaną wartość /Count. Nawet po odszyfrowaniu liczba stron jest brana z niezweryfikowanej deklaracji zamiast z przejścia drzewa stron.

pypdf przed wersją 6.21.3 może zużywać nadmierną pamięć, gdy tryb strict ładuje spreparowany nieprawidłowy słownik PDF. Zagnieżdżone błędy parsowania dodają powtarzający się tekst wyjątków do nowych błędów, przez co mały złośliwy słownik może rozrosnąć się do bardzo dużych komunikatów.

pypdf przed wersją 6.21.3 może potrzebować nadmiernego czasu na pobranie etykiet stron ze spreparowanego pliku PDF zawierającego płaskie drzewo numerów etykiet z wieloma zakresami. Właściwość page_labels przetwarza każdą stronę niezależnie i wielokrotnie skanuje tę samą tablicę /Nums od początku.

pypdf przed wersją 6.21.4 może wejść w nieskończoną pętlę podczas klonowania lub duplikowania spreparowanego cyklicznego DictionaryObject. Przejście klonowania sprawdzało wygenerowane referencje docelowe zamiast oryginalnych referencji źródłowych, co pozwalało niektórym cyklom źródłowym ominąć kontrolę odwiedzonych obiektów.

pypdf przed wersją 6.21.4 może zużywać nadmierną pamięć podczas parsowania spreparowanego drzewa stron PDF zawierającego wiele współdzielonych zasobów. Spłaszczanie drzewa stron kopiuje wpisy słownika stron i dziedziczonych zasobów bez ogólnego limitu wpisów, co powoduje nieproporcjonalne alokacje.

Biblioteka pypdf przed wersją 6.21.4 może wejść w nieskończoną pętlę podczas otwierania spreparowanego, niekompletnego pliku PDF, którego tablica referencji krzyżowych sięga końca pliku bez sekcji trailer. Wyszukiwanie trailera może wielokrotnie przewijać do tej samej pozycji strumienia zamiast zakończyć się, blokując wątek przetwarzający.

W Nuxt w wersjach od 4.6.0 do 4.6.3 serwer deweloperski zapisuje wygenerowany appSecret w pliku <buildDir>/app-secret (domyślnie .nuxt/app-secret) w katalogu dostępnym przez konfigurację Vite server.fs. Klient z bezpośrednim dostępem HTTP do wystawionego serwera deweloperskiego może pobrać ten plik, użyć deriveSecret() do wyliczenia pochodnych sekretów (np. domyślnego hasła useSession) i sfałszować ciasteczka sesji akceptowane przez ten serwer. Domyślne wiązanie do localhost ogranicza ekspozycję zdalną, a buildy produkcyjne i serwery z jawnie skonfigurowanym appSecret nie są podatne. Problem naprawiono w wersji 4.6.3.

W Nuxt w wersjach od 4.6.0 do 4.6.3 framework rozwiązuje literalne lub procentowo zakodowane segmenty kropkowe przed wyrenderowaniem strony, podczas gdy routing Nitro, sprawdzenia server/middleware i reguły tras serwera oceniają ścieżkę nierozwiązaną. Żądanie takie jak /%2e/admin może wyrenderować app/pages/admin.vue wraz z danymi renderowanymi po stronie serwera, podczas gdy sprawdzenia kluczowane na /admin, przekierowania i nagłówki bezpieczeństwa per trasa nie zadziałają. Handlery API, appMiddleware, Nuxt 3 oraz Nuxt 4.0.0–4.5.x nie są podatne, a wykorzystanie wymaga klienta wysyłającego segmenty kropkowe bez normalizacji przeglądarki. Problem naprawiono w wersji 4.6.3.

W Nuxt w wersjach od 3.0.0 do 4.6.3 serwer deweloperski może ujawnić pakiet deweloperski Nitro 2 pod <buildDir>/dev/index.mjs poprzez serwowanie plików Vite, gdy serwer jest osiągalny przez HTTP. Nitro wstawia do tego pakietu prywatne wartości runtimeConfig rozwiązywane w czasie budowania, w tym sekrety skonfigurowane w nuxt.config, a Nuxt 4.6.0 i nowsze wstawiają także wygenerowany deweloperski appSecret. Domyślne wiązanie do localhost ogranicza ekspozycję zdalną, buildy produkcyjne i Nitro 3 nie są podatne, a konfiguracja dostarczana wyłącznie przez zmienne środowiskowe NUXT_* przy starcie serwera nie jest wstawiana. Problem naprawiono w wersji 4.6.3.