MongoDB replike: uporaba po sprostitvi pred overitvijo lahko sesuje strežnike (CVE-2026-118383)

Kaj se je zgodilo

Dne 10. novembra 2026 je MongoDB razkril CVE-2026-118383, uporabo po sprostitvi (use-after-free) v komponenti za replikacijo strežnika MongoDB. Po CVSS ima oceno 9.0. Napaka se lahko pojavi, ko novo izvoljen primarni član replikacijskega nabora zaključi dohitevanje. Zahteve, ki ne zahtevajo overitve, jo lahko sprožijo. Posledica je lahko nenadna ustavitev procesa strežnika. Pod določenimi pogoji lahko napaka privede tudi do poljubnega izvajanja kode v okviru procesa strežnika.

Po poročanju portala The Hacker News je tveganje za član replikacijskega nabora, ki je zaostal in nato postane primarni, na primer med preklopom. MongoDB je izdal popravke. Ranljivost ni navedena v katalogu znanih izkoriščenih ranljivosti agencije CISA, noben vir pa ne poroča o napadih.

Kdo je prizadet

• Prizadeti: procesi mongod, ki delujejo kot člani replikacijskega nabora. To vključuje replikacijske nabore shardov in replikacijske nabore config strežnikov v shardiranih gručah.
• Niso prizadeti: samostojne instance mongod, ki niso del replikacijskega nabora.

Napako je mogoče sprožiti pred overitvijo, zato vklop overitve ne varuje. Največje tveganje je za člane replikacijskih naborov, do katerih lahko dostopajo nezaupanja vredna omrežja ali mnogo aplikacijskih gostiteljev.

Kaj storiti zdaj

1. Popišite svoje člane replikacijskega nabora. Na vsakem strežniku MongoDB preverite, ali mongod deluje kot del replikacijskega nabora (glejte naslednji razdelek). Samostojne instance za to CVE ne zahtevajo takojšnjega ukrepanja.
2. Poiščite popravljeno različico za svojo serijo izdaj. Vstopnica MongoDB SERVER-138119 (povezava spodaj) je del popravka. Navaja popravljene različice 9.0.7, 8.3.16, 8.0.37, 7.0.48, 6.0.30, 5.0.35 in 4.4.32. Primerjajte jo s SERVER-138175, da potrdite različico za svojo serijo.
3. Varnostno kopirajte konfiguracijo. Shranite /etc/mongod.conf (ali ustrezno datoteko pri vas) in preverite, ali obstaja nedavna varnostna kopija podatkov.
4. Posodabljajte po enega člana naenkrat. Začnite s sekundarnimi strežniki. Posodobite paket (na primer apt install mongodb-org ali dnf update mongodb-org), znova zaženite mongod in počakajte, da član v rs.status() znova prikaže stanje SECONDARY. Nato na primarnem strežniku zaženite rs.stepDown() in ga posodobite nazadnje. V shardiranih gručah posodobite replikacijski nabor config strežnikov in vse replikacijske nabore shardov.
5. Omejite omrežni dostop. Vrata 27017 (ali vaša prilagojena vrata) naj bodo dosegljiva le z aplikacijskih strežnikov in drugih članov gruče. To uveljavite z ognjeno steno ali nastavitvijo bindIp, tako zdaj kot po posodobitvi.
6. Spremljajte morebitne zrušitve. Preverite dnevnike mongod in spremljanje storitev za nenadne ponovne zagone, zlasti ob volitvah in preklopih.

Kako preveriti, ali ste prizadeti

• Različico preverite z mongod --version ali v mongosh z db.version().
• Članstvo v replikacijskem naboru preverite v mongosh z db.hello().setName. Če se vrne ime, je instanca član replikacijskega nabora in je prizadeta, dokler je ne posodobite. Če se ne vrne nič in rs.status() javi, da instanca ne deluje z replikacijo, je samostojna instanca in ni prizadeta.
• Pri shardiranih gručah preverite vsakega člana vsakega shard in vsakega config strežnika.
• Če je član na starejši različici, kot je popravljena različica za njegovo serijo izdaj, ga posodobite.

Viri

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