Katalog podatności CVE

W publicznej wersji rozwojowej music-metadata wprowadzonej po 11.14.0 regresja w gałęzi rozwojowej parsera opisu próbki MP4 stsd pozwala na kontrolowany przez atakującego rozmiar wpisu próbki równy zero, co uniemożliwia przesunięcie kursora StsdAtom.get, podczas gdy kontrolowany przez atakującego entry_count utrzymuje działanie pętli synchronicznej. Spreparowane dane wejściowe z rodziny MP4 mogą zablokować pętlę zdarzeń Node.js i zwiększać tabelę opisu próbek, aż proces zostanie zakończony lub wyczerpie pamięć. Podatna zmiana była obecna w publicznej gałęzi master, ale nie została uwzględniona w music-metadata 11.14.0 ani żadnym wcześniejszym wydaniu npm, a wersja 11.16.0 zawiera poprawkę.

W bibliotece music-metadata przed wersją 11.16.0 parser MP4 akceptuje kontrolowany przez atakującego 64-bitowy rozszerzony rozmiar atomu, konwertuje go na liczbę JavaScript i używa wynikowej długości ładunku do wywołań readToken specyficznych dla atomu, zanim udowodni, że atom mieści się w swoim rodzicu lub dostępnych danych wejściowych. Mały plik z rodziny MP4 może skierować zbyt dużą długość do parsowania ładunku dla atomów takich jak mvhd, stsd, stsz i date, powodując próbę dużej alokacji lub awarię procesu przed walidacją końca danych wejściowych. Aplikacje parsujące niezaufane media z rodziny MP4 mogą w związku z tym doświadczyć odmowy usługi.

W bibliotece music-metadata przed wersją 11.16.0 parser EBML dla Matroska i WebM dekoduje kontrolowaną przez atakującego długość elementu VINT i używa jej do alokacji tokenu ciągu lub Uint8Array, zanim potwierdzi, że liść mieści się w swoim rodzicu lub dostępnych danych wejściowych. Spreparowane dane wejściowe WebM, MKV lub MKA mogą powodować nieproporcjonalne alokacje, odmowę usługi z powodu wyczerpania pamięci lub, w wykazanym przypadku ścieżki parseFile w Node.js 26.7.0, nieprzechwytywalne fatalne przerwanie V8. Dokładny tryb awarii zależy od tokenizera, API parsera i środowiska uruchomieniowego, ale wspólna wada walidacji długości liścia ma wpływ tylko na dostępność.

Koder BSON w sterowniku MongoDB PHP nie sprawdza niektórych wartości zwracanych, gdy dokument przekracza limit rozmiaru libbson. Może to pozostawić koder w nieprawidłowym stanie. Nieuwierzytelniony podmiot, który może spowodować, że podatna aplikacja zakoduje nietypowo dużą strukturę danych, może zakończyć proces roboczy PHP lub spowodować pominięcie pól w wynikowym dokumencie. Nie jest wymagane połączenie z serwerem MongoDB ani uwierzytelnienie w bazie danych.

IBM Guardium Data Protection 12.0, 12.1, 12.2 jest podatny na niewłaściwą walidację wskaźników dostarczonych przez użytkownika w sterowniku jądra WfpMonitor. Niektóre procedury obsługi IOCTL METHOD_NEITHER wyłuskują wskaźniki kontrolowane przez użytkownika bez odpowiedniego sprawdzenia i obsługi wyjątków, co potencjalnie pozwala uprzywilejowanemu lokalnemu atakującemu na spowodowanie awarii systemu lub wykonanie ograniczonych odczytów pamięci jądra.

W bibliotece music-metadata przed wersją 11.16.0 parser ID3v2 ufa polu rozmiaru znacznika syncsafe i alokuje całe ciało znacznika, zanim sprawdzi, czy dane wejściowe zawierają zadeklarowane bajty. Obcięty plik zawierający tylko nagłówek ID3v2 może zażądać alokacji zbliżonej do 268 MiB; alokacja się udaje, kolejny odczyt osiąga koniec strumienia, EndOfStreamError jest przechwytywany wewnętrznie, a wywołujący otrzymuje normalny obiekt metadanych.

Przed wersją 11.16.0 parser APEv2 w bibliotece music-metadata odczytuje rozmiar elementu sterowany przez atakującego i przydziela Uint8Array dla elementu binarnego przed sprawdzeniem, czy zadeklarowany rozmiar mieści się w pozostałych danych. Mały spreparowany plik APE może wywołać nieproporcjonalną alokację pamięci, a wielokrotne lub równoległe parsowanie może wyczerpać pamięć procesu. Problem został naprawiony w wersji 11.16.0.

W bibliotece amqp091-go (klient AMQP 0.9.1 dla Go) w wersjach od 1.13.0 do 1.14.0 można obejść mechanizm ograniczania rozmiaru ramki przed zakończeniem negocjacji connection.tune, ponieważ Connection.maxFrameSize używa zera zarówno dla stanu nieuzgodnionego, jak i dla stanu bez limitu. Złośliwy lub skompromitowany peer AMQP może wysłać krótki nagłówek ramki z dużym zadeklarowanym rozmiarem ładunku, powodując alokację pamięci wybranej przez atakującego przed odebraniem ładunku lub odrzuceniem stanu protokołu. Problem został naprawiony w wersji 1.14.0.

W MariaDB Connector/Node.js w wersjach od 3.3.0 do 3.5.4, ścieżka walidacji odcisku palca TLS przy zerowej konfiguracji wywołuje Ed25519PasswordAuth.hash() przez Authentication.validateFingerPrint, ale Ed25519PasswordAuth.hash() odwołuje się do identyfikatora seed, który nie jest w zakresie. W określonych warunkach (serwer MariaDB przez TCP, TLS z ssl: true lub obiektem ssl z rejectUnauthorized nie równym false, ustawione hasło, brak ssl.ca, negocjowany plugin client_ed25519) może wystąpić synchroniczny ReferenceError, który w domyślnym zachowaniu Node.js powoduje zakończenie procesu klienta (odmowa usługi). Problem został naprawiony w wersji 3.5.4.

Nieprawidłowa walidacja długości tablicy BSON w MongoDB Go Driver może spowodować odczyt poza zakresem i panikę w czasie wykonywania, gdy aplikacja wywołuje bson.RawArray.Validate lub bsoncore.Array.Validate na nieprawidłowej czterobajtowej tablicy. Nieuwierzytelniony atakujący, który może dostarczyć surowe dane tablicy BSON do podatnej aplikacji, może zakończyć proces aplikacji, powodując odmowę usługi.

Przepełnienie liczby całkowitej w obsłudze długości wartości BSON w MongoDB Go Driver może spowodować panikę w czasie wykonywania, gdy aplikacja waliduje lub uzyskuje dostęp do nieprawidłowego dokumentu BSON. Nieuwierzytelniony atakujący, który może dostarczyć bajty BSON do podatnej aplikacji, może zakończyć proces aplikacji, powodując odmowę usługi.

Nieprawidłowe obliczenia w parsowaniu ciągów Decimal128 w MongoDB C Driver mogą akceptować pewne dane wejściowe z nadmierną precyzją zawierające wiodące zera zamiast je odrzucać. To powoduje, że wartość różni się od dostarczonego tekstu. Atakujący, który może dostarczyć ciąg dziesiętny do aplikacji osadzającej, w tym przez parsowanie Extended JSON, może spowodować, że aplikacja zapisze lub użyje nieprawidłowej wartości numerycznej.

API rezerwacji bufora BSON w MongoDB C Driver może zarejestrować długość mniejszą niż minimalna pięciobajtowa długość BSON. Późniejsze operacje dołączania lub porównywania mogą spowodować niedomiar w obliczeniach długości bez znaku i odczyt lub zapis poza buforem dokumentu. Atakujący, który może wpłynąć na długość dostarczoną przez aplikację osadzającą, może spowodować zakończenie aplikacji lub odczytanie/uszkodzenie sąsiedniej pamięci procesu.

Komponent jawnego odszyfrowania w MongoDB libmongocrypt może zwrócić niezmieniony, nierozpoznany zaszyfrowany payload zamiast zwrócić błąd odszyfrowania. Atakujący, który może modyfikować przechowywane zaszyfrowane pola (np. zapisujący do bazy, serwer lub pośrednik sieciowy), może spowodować, że aplikacja przetworzy dostarczone bajty jako odszyfrowany tekst jawny.

Błąd off-by-one w bulk writerze dokumentów BSON w MongoDB C Driver może zapisać jeden bajt zerowy tuż poza alokacją sterty, gdy dokument kończy się na określonej granicy bufora. Atakujący, który może wpłynąć na rozmiar dokumentów serializowanych przez aplikację osadzającą, może uszkodzić sąsiednią pamięć procesu lub zakończyć proces.

MongoDB C++ Driver odrzuca zawartość po wbudowanym bajcie NUL w niektórych nazwach pól i kolekcji akceptowanych przez API kolekcji. To może spowodować, że sterownik i aplikacja będą interpretować tę samą nazwę różnie. Uwierzytelniony atakujący, który może wpłynąć na nazwę przekazaną przez aplikację, może spowodować, że aplikacja odczyta różne wartości z niezamierzonego pola lub zmieni nazwę niezamierzonej kolekcji.

Podatność w MongoDB libmongocrypt powoduje niedomiar liczby całkowitej w logice analizy punktów końcowych KMS, co może prowadzić do błędu alokacji i zakończenia procesu aplikacji. Problem występuje, gdy uwierzytelniony użytkownik modyfikuje dokument klucza w kolekcji key vault lub gdy aplikacja akceptuje punkt końcowy KMS zawierający dwukropek po ścieżce lub zapytaniu podczas tworzenia klucza. Podatność nie uzyskuje dostępu do pamięci poza przydzielonymi granicami.

Docker Sandboxes porównywały nazwy hostów punktów końcowych tokenów OAuth w sposób uwzględniający wielkość liter przy decydowaniu, czy maskować odpowiedzi zarządzanych poświadczeń, podczas gdy routing żądań traktował nazwy DNS bez uwzględniania wielkości liter. Niezaufany kod w sandboxie mógł użyć nazwy hosta z różną wielkością liter, aby dotrzeć do prawdziwego punktu końcowego dostawcy, omijając maskowanie odpowiedzi. Jeśli użytkownik ukończył przepływ OAuth, tokeny dostępu i odświeżania dostawcy mogły zostać zwrócone bez maskowania do sandboxa, ujawniając poświadczenia zarządzane przez hosta.

Docker Sandboxes mogły przekazywać poświadczenia dostarczone przez klienta wraz z poświadczeniem wstrzykniętym przez hosta przez proxy egress. Proxy usuwało alternatywne poświadczenia tylko wtedy, gdy ich wartości pasowały do znanych wartości sentinel, więc niezaufany kod w autoryzowanym sandboxie mógł dostarczyć nierozpoznane poświadczenie w innym obsługiwanym nagłówku autoryzacji. Dla dotkniętych usług zewnętrznych mogło to uwierzytelnić żądanie na koncie kontrolowanym przez atakującego i ujawnić dane zawarte w żądaniu.

Docker Sandboxes mogły zawieść w trybie otwartym podczas maskowania poświadczeń w chronionych odpowiedziach proxy. Gdy odczyt treści odpowiedzi zwracał dane wraz z błędem, dotknięte procedury mogły przekazywać niezmaskowane bajty. Kod wewnątrz autoryzowanego sandboxa mógł to wykorzystać do odzyskania zarządzanych przez hosta tokenów OAuth dostępu i odświeżania lub pochodnego klucza API Anthropic, który miał pozostać poza sandboxem.