Katalog podatności CVE

Webhook dbt Cloud w Lightdash (POST /api/v1/projects/{projectUuid}/dbt-cloud/webhook) nie ma uwierzytelniania ani walidacji podpisu. Wartości accountId i runId z żądania są wstawiane do adresu URL API dbt Cloud po stronie serwera, co umożliwia path traversal i wysłanie żądania z kluczem API ofiary.

HashiCorp Boundary i Boundary Enterprise mają podatność SSRF w integracji magazynu poświadczeń Vault. Uwierzytelniony użytkownik z uprawnieniami do zarządzania magazynami poświadczeń może spowodować, że kontroler Boundary wykona żądania wychodzące do wybranego celu sieciowego i otrzyma odpowiedź.

Motyw Bricks Theme 2.4 i wcześniejsze dla WordPressa zawiera nieuwierzytelnioną podatność broken access control w punkcie końcowym REST load_popup_content. Anonimowy atakujący może odczytać treść szkiców i niepublikowanych stron, podając parametr popupId bez sprawdzania statusu lub uprawnień.

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.11 ma implementacje MariaDbPoolConnection.recover() i MariaDbPoolPinnedConnection.recover(), które ufają kolumnom gtrid_length i bqual_length zwracanym przez XA RECOVER. Metody te alokują i dzielą tablice bajtów Xid bez walidacji długości względem Xid.MAXGTRIDSIZE, Xid.MAXBQUALSIZE lub rzeczywistego ładunku danych. Złośliwy lub przejęty serwer albo atakujący typu man-in-the-middle może spowodować duże alokacje, NegativeArraySizeException lub ArrayIndexOutOfBoundsException podczas odzyskiwania XA. Problem 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.

Biblioteka @hapi/content w wersjach od 3.0.6 do 6.0.3 używa niezakotwiczonego wyrażenia nazwy parametru w globalnym skanowaniu wyrażeń regularnych, co powoduje powtarzające się nieudane dopasowania przy długim tokenie bez znaku równości w nagłówku Content-Disposition. Powstałe przetwarzanie kwadratowe może zablokować pętlę zdarzeń Node.js przed obsługą tras, w tym na nieuwierzytelnionych trasach hapi z włączonym payload.multipart.

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.