MongoDB opravuje kritickou chybu v replikaci: útočník bez přihlášení může shodit server, za určitých podmínek i spustit kód

Co se stalo

MongoDB zveřejnil 10. listopadu 2026 bezpečnostní alert ke zranitelnosti CVE-2026-118383 v databázovém serveru MongoDB Server. Jde o chybu typu use-after-free (CWE-416) v replikaci. Přidělující autorita (MongoDB) ji hodnotí CVSS 4.0 9,5 a CVSS 3.1 9,0 – kritická závažnost. Opravené verze vyšly pro všechny větve od 4.4 po 9.0.

Podle MongoDB chybu lze spustit požadavky bez přihlášení. Výsledkem je pád serveru, za určitých podmínek i spuštění libovolného kódu. Chybu našel MongoDB interně, o zneužívání nepíše.

Ve stejný den MongoDB vydal alerty i k dalším chybám (např. CVE-2026-120828, vyčerpání paměti, 8,7). Tento článek se věnuje té nejvážnější.

Technické podrobnosti

• Komponenta: replikace v MongoDB Server, konkrétně fáze dohánění dat (catch-up) po volbě nového primárního uzlu replica setu.
• Typ chyby: použití uvolněné paměti. Podle záznamu SERVER-138175 šlo o opětovný vstup (re-entrancy) do funkce CatchupState::abort().
• Podmínky: útočník potřebuje jen síťový přístup k členu replica setu, přihlášení ani součinnost uživatele ne. Chyba se ale projeví jen ve chvíli, kdy nově zvolený primární uzel dokončuje dohánění dat – proto vysoká složitost útoku (AC:H).
• Oprava: kromě odstranění chyby MongoDB v rámci SERVER-138119 omezil volbu readConcern afterOpTime jen na interní systémové uživatele.

Pro kontext: replica set je běžný způsob provozu MongoDB v produkci – jeden primární uzel přijímá zápisy, sekundární uzly drží kopii dat a při výpadku si zvolí nového primárního. Ten si nejdřív od ostatních členů dotáhne nejnovější zápisy, které ještě neměl (fáze catch-up, délku řídí nastavení settings.catchUpTimeoutMillis), a teprve potom začne přijímat zápisy. Právě při ukončení této fáze chyba nastává.

MongoDB ukázkový kód nezveřejnil a my ho nepřinášíme.

Koho se to týká

Zasažení jsou členové replica setů, včetně členů shardů a config serverů. Samostatný mongod podle MongoDB zasažený není. Verzi a roli zjistíte v mongosh:

db.version()
rs.status().members.map(m => [m.name, m.stateStr])

Jak poznat napadení

MongoDB indikátory napadení nezveřejnil. Z praxe doporučujeme:

• Projděte log mongod kolem voleb primárního uzlu (záznamy o election a catchup) a hledejte neočekávané pády procesu nebo restarty od systemd či Kubernetes.
• Zkontrolujte, odkud se k portu databáze (výchozí 27017) připojovaly adresy mimo vaše aplikační servery. Adresy z logu rychle vytáhnete naším extraktorem IOC – běží jen ve vašem prohlížeči.
• Při podezření na spuštění kódu prověřte procesy a soubory spuštěné pod uživatelem, pod kterým běží mongod.

Co udělat

1. Aktualizujte všechny členy replica setu na opravenou verzi své větve – postupně, nejdřív sekundární uzly, nakonec primární (po rs.stepDown()). Uvědomte si, že volba nového primárního uzlu je přesně chvíle, kdy se chyba projevuje – do aktualizace omezte síťový přístup.
2. Omezte přístup k databázi: port MongoDB má být dostupný jen z aplikačních serverů a ostatních členů clusteru (firewall, net.bindIp). Přihlášení proti této chybě nechrání. To je naše doporučení, MongoDB dočasná řešení neuvádí.
3. Zjistěte, kde databáze naslouchá: na serveru ss -tlnp | grep mongod a v /etc/mongod.conf hodnotu net.bindIp. Adresa 0.0.0.0 znamená všechna rozhraní – pak musí přístup hlídat firewall.
4. Ověřte verzi příkazem db.version() na každém členu po aktualizaci.
5. Balíčky z distribucí a obrazy kontejnerů (mongo:8.0 apod.) aktualizujte podle jejich vydavatele.

Časová osa

Aktualizace

• 12. 11. 2026 – první verze článku.