MongoDB-replikasett: use-after-free før autentisering kan krasje servere (CVE-2026-118383)

Hva skjedde

Den 10. november 2026 offentliggjorde MongoDB CVE-2026-118383, en use-after-free i replikeringskomponenten i MongoDB Server. Feilen har CVSS-score 9.0. Feilen kan oppstå når en nylig valgt primær i et replikasett fullfører synkroniseringen. Forespørsler som ikke krever autentisering kan utløse den. Resultatet kan være at serverprosessen stopper uventet. Under visse forhold kan den også føre til vilkårlig kodekjøring i konteksten til serverprosessen.

Ifølge The Hacker News gjelder risikoen et medlem av et replikasett som har kommet etter i replikeringen og deretter blir primær, for eksempel under en failover. MongoDB har sluppet rettelser. Sårbarheten står ikke i CISAs katalog over kjent utnyttede sårbarheter, og ingen av kildene rapporterer angrep.

Hvem er berørt

• Berørt: mongod-prosesser som kjører som medlemmer av et replikasett. Dette gjelder shard-replikasett og config-server-replikasett i shardede klynger.
• Ikke berørt: frittstående mongod-instanser som ikke er del av et replikasett.

Feilen kan utløses før autentisering, så å slå på autentisering beskytter deg ikke. Den høyeste risikoen gjelder replikasettmedlemmer som er nåbare fra utrygge nettverk eller mange applikasjonsservere.

Hva du bør gjøre nå

1. Lag en liste over replikasettmedlemmene dine. Sjekk på hver MongoDB-server om mongod kjører som del av et replikasett (se neste avsnitt). Frittstående instanser trenger ingen haster-tiltak for denne CVE-en.
2. Finn rettet versjon for din utgivelsesserie. MongoDB-saken SERVER-138119 (lenket nedenfor) er en del av rettelsen. Den lister rettede versjoner 9.0.7, 8.3.16, 8.0.37, 7.0.48, 6.0.30, 5.0.35 og 4.4.32. Sammenlign dette med SERVER-138175 for å bekrefte versjonen for din serie.
3. Sikkerhetskopier konfigurasjonen. Lagre /etc/mongod.conf (eller tilsvarende) og bekreft at en nylig sikkerhetskopi av dataene finnes.
4. Oppgrader ett medlem om gangen. Start med sekundærene. Oppgrader pakken (for eksempel apt install mongodb-org eller dnf update mongodb-org), start mongod på nytt og vent til medlemmet viser SECONDARY igjen i rs.status(). Kjør deretter rs.stepDown() på primæren og oppgrader den sist. I shardede klynger oppgraderer du config-server-replikasettet og alle shard-replikasettene.
5. Begrens nettverkstilgang. Port 27017 (eller din egendefinerte port) bør bare være nåbar fra applikasjonsservere og de andre klyngemedlemmene. Bruk brannmuren eller bindIp for å håndheve dette, både nå og etter oppdateringen.
6. Hold øye med krasj. Sjekk mongod-loggene og overvåkingen av tjenesten din for uventede omstarter, særlig rundt valg og failovere.

Slik sjekker du om du er berørt

• Sjekk versjonen med mongod --version, eller i mongosh med db.version().
• Sjekk medlemskapet i replikasettet i mongosh med db.hello().setName. Hvis et navn returneres, er instansen et replikasettmedlem og er berørt til den er oppdatert. Hvis ingenting returneres og rs.status() melder at instansen ikke kjører med replikering, er den frittstående og ikke berørt.
• For shardede klynger kjører du sjekken på alle shard-medlemmer og alle config-server-medlemmer.
• Hvis et medlem er på en eldre versjon enn den rettede versjonen for sin utgivelsesserie, oppgrader det.

Kilder

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