MongoDB replica sets: pre-auth use-after-free can crash servers (CVE-2026-118383)

Co się wydarzyło

W dniu 10 listopada 2026 roku MongoDB ujawniło CVE-2026-118383, błąd typu use-after-free w komponencie replikacji MongoDB Server. Otrzymał ocenę 9.0 w skali CVSS. Problem może wystąpić, gdy nowo wybrany główny węzeł zestawu replik kończy synchronizację zaległych danych. Do jego wywołania mogą wystarczyć żądania, które nie wymagają uwierzytelnienia. Skutkiem może być nieoczekiwane zatrzymanie procesu serwera. W określonych warunkach może to również prowadzić do wykonania dowolnego kodu w kontekście procesu serwera.

Serwis The Hacker News podaje, że ryzyko dotyczy członka zestawu replik, który wcześniej zostawał w tyle, a następnie staje się węzłem głównym, na przykład podczas przełączenia awaryjnego. MongoDB udostępniło poprawki. Podatność nie znajduje się w katalogu znanych wykorzystywanych podatności CISA, a żadne ze źródeł nie raportuje ataków.

Kto jest dotknięty

• Dotknięte: procesy mongod działające jako członkowie zestawu replik. Dotyczy to zestawów replik shardów i zestawów replik serwerów konfiguracyjnych klastrów shardowanych.
• Niedotknięte: samodzielne instancje mongod, które nie są częścią zestawu replik.

Błąd może zostać wywołany przed uwierzytelnieniem, dlatego samo włączenie uwierzytelniania nie chroni systemu. Najwyższe ryzyko dotyczy członków zestawów replik, do których mają dostęp niezaufane sieci lub wiele hostów aplikacji.

Co zrobić teraz

1. Wypisz członków swoich zestawów replik. Na każdym serwerze MongoDB sprawdź, czy mongod działa w ramach zestawu replik (zob. następną sekcję). Samodzielne instancje nie wymagają pilnych działań w związku z tym CVE.
2. Znajdź wersję poprawioną dla swojej serii wydań. Zgłoszenie MongoDB SERVER-138119 (podlinkowane poniżej) dotyczy poprawki. Wymienia wersje naprawcze 9.0.7, 8.3.16, 8.0.37, 7.0.48, 6.0.30, 5.0.35 i 4.4.32. Porównaj to z SERVER-138175, aby potwierdzić wersję dla swojej serii.
3. Wykonaj kopię zapasową konfiguracji. Zapisz /etc/mongod.conf (lub odpowiednik w Twoim środowisku) i upewnij się, że istnieje aktualna kopia zapasowa danych.
4. Aktualizuj jednego członka naraz. Zacznij od węzłów wtórnych. Zaktualizuj pakiet (na przykład apt install mongodb-org lub dnf update mongodb-org), uruchom ponownie mongod i poczekaj, aż członek ponownie wyświetli stan SECONDARY w rs.status(). Następnie wykonaj rs.stepDown() na węźle głównym i zaktualizuj go jako ostatni. W klastrach shardowanych zaktualizuj zestaw replik serwerów konfiguracyjnych oraz każdy zestaw replik shardów.
5. Ogranicz dostęp sieciowy. Port 27017 (lub Twój niestandardowy port) powinien być dostępny wyłącznie z serwerów aplikacji i pozostałych członków klastra. Użyj zapory sieciowej lub bindIp, aby to wymusić, zarówno teraz, jak i po aktualizacji.
6. Monitoruj awarie. Sprawdzaj logi mongod oraz monitoring usług pod kątem nieoczekiwanych ponownych uruchomień, szczególnie podczas wyborów i przełączeń awaryjnych.

Jak sprawdzić, czy jesteś dotknięty

• Sprawdź wersję poleceniem mongod --version lub w mongosh poleceniem db.version().
• Sprawdź przynależność do zestawu replik w mongosh poleceniem db.hello().setName. Jeśli zwrócona zostanie nazwa, instancja jest członkiem zestawu replik i pozostaje dotknięta do czasu aktualizacji. Jeśli nic nie zostanie zwrócone, a rs.status() informuje, że instancja nie działa z replikacją, jest to samodzielna instancja i nie jest ona podatna.
• W klastrach shardowanych wykonaj sprawdzenie na każdym członku shardu i każdym członku serwerów konfiguracyjnych.
• Jeśli członek działa w starszej wersji niż poprawiona dla jego serii wydań, zaktualizuj go.

Źródła

• https://nvd.nist.gov/vuln/detail/CVE-2026-118383
• https://jira.mongodb.org/browse/SERVER-138119