CVE-2026-82052

Nieautoryzowany użytkownik z dostępem do zapisu w magazynie kluczy może spowodować, że autoryzowany klient wyśle dowolne uwierzytelnione żądania do Google Cloud KMS pod tożsamością autoryzowanego użytkownika, eskalując dostęp na poziomie bazy danych do kontroli kluczy w chmurze i omijając szyfrowanie po stronie klienta.

W MongoDB 2.6, przy użyciu użytkowników w stylu 2.4, zdalni atakujący mogą spowodować odmowę usługi poprzez wykorzystanie reprezentacji bazy danych w pamięci podczas próby uwierzytelnienia w nieistniejącej bazie danych.

MongoDB w wersjach 3.4.x przed 3.4.10 oraz 3.5.x-development ma domyślnie wyłączoną konfigurację networkMessageCompressors, która, gdy jest włączona, może być wykorzystana przez złośliwego atakującego do odmowy usługi lub modyfikacji pamięci.

Nieograniczone zużycie zasobów w procesie routera klastra sharded MongoDB. Klient z dostępem sieciowym do portu routera, bez uwierzytelnienia, może wysyłać parametry monitorowania połączeń, które powodują nadmierne zużycie CPU bez ograniczania szybkości, co pogarsza lub uniemożliwia działanie usługi dla legalnych klientów. Nie wymaga uwierzytelnienia ani interakcji użytkownika. Wpływa tylko na dostępność, nie na poufność ani integralność danych.

Podatność w kodzie generowania błędów walidacji JSON Schema w MongoDB pozwala uwierzytelnionemu użytkownikowi z uprawnieniami readWrite na awarię serwera mongod. Gdy dokument BSON zawierający tablicę z nieprawidłową nazwą pola numerycznego nie spełnia ograniczenia typu items w $jsonSchema, ścieżka generowania błędu wykonuje niebezpieczną konwersję numeryczną na nazwie pola kontrolowanej przez użytkownika bez odpowiedniej obsługi wyjątków, co powoduje nieprzechwycony wyjątek i zakończenie procesu serwera. Jest to możliwe, ponieważ walidacja BSON w protokole sieciowym nie egzekwuje, że nazwy pól elementów tablicy są prawidłowymi, mieszczącymi się w zakresie indeksami numerycznymi.

Odkryto problem bezpieczeństwa w MongoDB, gdzie uwierzytelniony użytkownik z uprawnieniami readWrite może spowodować awarię procesu serwera mongod. Poprzez podanie niestandardowej opcji konfiguracji WiredTiger z niezgodną wartością podczas tworzenia kolekcji, użytkownik może wywołać pomyłkę typu w warstwie silnika składowania. Gdy dokumenty są następnie odczytywane z nieprawidłowo skonfigurowanej kolekcji, wynikająca z tego niezgodność w oczekiwanym formacie danych prowadzi do uszkodzonej interpretacji pamięci i awarii serwera. Spreparowana konfiguracja kolekcji utrzymuje się po ponownych uruchomieniach, wymagając ręcznej interwencji operatora w celu naprawy.

Błąd wyścigu w parsowaniu zapytań indeksu tekstowego serwera MongoDB może powodować odczyt po zwolnieniu (use-after-free) na stercie podczas obsługi ścieżek ponawiania operacji upsert. W pewnych współbieżnych operacjach na cyklu życia indeksu, surowy wskaźnik do wewnętrznych metadanych indeksu tekstowego może być wyłuskiwany po zwolnieniu podstawowych struktur, co prowadzi do awarii serwera. Uwierzytelniony użytkownik z uprawnieniami readWrite może wywołać ten stan poprzez określone współbieżne operacje wyszukiwania tekstowego i zarządzania indeksem, co powoduje denial of service dla wszystkich podłączonych klientów.

Problem bezpieczeństwa w generowaniu kluczy indeksu 2dsphere w MongoDB może powodować awarię serwera z powodu wyłuskania pustego wskaźnika. Gdy specjalnie spreparowany dokument GeoJSON jest wstawiany do kolekcji z indeksem 2dsphere, niespójność w parsowaniu geometrii może pozostawić wewnętrzny obiekt w nieprawidłowym, częściowo zainicjalizowanym stanie. Podczas późniejszego generowania klucza indeksu, dostęp do tego nieprawidłowo zainicjalizowanego obiektu powoduje wyłuskanie pustego wskaźnika, co kończy proces mongod. Uwierzytelniony użytkownik z prawem zapisu może to wykorzystać do spowodowania denial of service.

Problem bezpieczeństwa istnieje w parserze JSON Pointer serwera MongoDB używanym podczas przetwarzania filtrów zapytań $jsonSchema. Gdy polecenie find zawiera specjalnie spreparowane pole filtra $jsonSchema, parser przetwarza dane wejściowe bez egzekwowania odpowiednich limitów liczby iteracji lub całkowitego rozmiaru alokacji, co powoduje znaczną amplifikację pamięci. Pod współbieżnym obciążeniem żądaniami, skumulowane zużycie pamięci może wyczerpać dostępną pamięć sterty, powodując, że mechanizm obsługi braku pamięci serwera kończy proces mongod i odmawia usługi wszystkim podłączonym klientom.

Podczas planowania zapytań w MongoDB, przy odczytywaniu wzorca sortowania w surowej formie BSONObj, w niektórych miejscach nie obsłużono jawnie przypadku wyrażenia meta. Może to prowadzić do nieprawidłowych transformacji i błędu invariant failure.