MongoDB-replikasæt: use-after-free før autentificering kan få servere til at ggå ned (CVE-2026-118383)

Hvad skete der

Den 10. november 2026 offentliggjorde MongoDB CVE-2026-118383, en use-after-free i replikeringskomponenten i MongoDB Server. Den er vurderet til 9.0 i CVSS. Fejlen kan opstå, når en nyligt valgt primær i et replikasæt afslutter sin indhentning. Forespørgsler, der ikke kræver autentificering, kan udløse den. Resultatet kan være, at serverprocessen stopper uventet. Under visse betingelser kan den også føre til vilkårlig kodeafvikling i serverprocessens kontekst.

Ifølge The Hacker News er risikoen for et replikasætmedlem, der er kommet bagud og derefter bliver primær, for eksempel under en failover. MongoDB har udgivet rettelser. Sårbarheden står ikke i CISA's katalog over kendt udnyttede sårbarheder, og ingen af kilderne rapporterer angreb.

Hvem er berørt

• Berørt: mongod-processer, der kører som medlemmer af et replikasæt. Det omfatter shard-replikasæt og config-server-replikasæt i shardede klynger.
• Ikke berørt: selvstændige mongod-instanser, som ikke er en del af et replikasæt.

Fejlen kan udløses før autentificering, så det hjælper ikke at slå autentificering til. Den største risiko gælder replikasætmedlemmer, som utroede netværk eller mange applikationsværter kan nå.

Det skal du gøre nu

1. Find dine replikasætmedlemmer. Tjek på hver MongoDB-server, om mongod kører som en del af et replikasæt (se næste afsnit). Selvstændige instanser kræver ingen akut handling for denne CVE.
2. Find rettelsesversionen for din udgaveserie. MongoDB-sagen SERVER-138119 (linket nedenfor) er en del af rettelsen. Den angiver rettelsesversionerne 9.0.7, 8.3.16, 8.0.37, 7.0.48, 6.0.30, 5.0.35 og 4.4.32. Sammenlign med SERVER-138175 for at bekræfte versionen for din serie.
3. Sikkerhedskopier din konfiguration. Gem /etc/mongod.conf (eller din tilsvarende fil) og bekræft, at en nylig backup af dine data findes.
4. Opdater ét medlem ad gangen. Start med sekundærerne. Opdater pakken (for eksempel apt install mongodb-org eller dnf update mongodb-org), genstart mongod, og vent, til medlemmet igen viser SECONDARY i rs.status(). Kør derefter rs.stepDown() på primæren og opdater den til sidst. I shardede klynger opdaterer du config-server-replikasættet og alle shard-replikasæt.
5. Begræns netværksadgang. Port 27017 (eller din tilpassede port) bør kun kunne nås fra applikationsservere og de øvrige klyngemedlemmer. Brug din firewall eller bindIp til at håndhæve dette, både nu og efter opdateringen.
6. Hold øje med nedbrud. Tjek mongod-logfilerne og din overvågning for uventede genstarter, især omkring valg og failovers.

Sådan tjekker du, om du er berørt

• Tjek versionen med mongod --version eller i mongosh med db.version().
• Tjek replikasætmedlemskab i mongosh med db.hello().setName. Hvis der returneres et navn, er instansen et replikasætmedlem og er berørt, indtil den er opdateret. Hvis intet returneres, og rs.status() oplyser, at instansen ikke kører med replikering, er den en selvstændig instans og er ikke berørt.
• For shardede klynger kører du tjekket på alle shard-medlemmer og alle config-server-medlemmer.
• Hvis et medlem kører en ældre version end rettelsesversionen for sin udgaveserie, skal du opdatere det.

Kilder

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