MongoDB-replikaset: use-after-free före autentisering kan krascha servrar (CVE-2026-118383)

Vad hände

Den 10 november 2026 offentliggjorde MongoDB CVE-2026-118383, en use-after-free i replikeringskomponenten i MongoDB Server. Den har betyget 9.0 enligt CVSS. Bristen kan uppstå när en nyligen vald primär nod i ett replikaset slutför uppkörningen. Förfrågningar som inte kräver autentisering kan utlösa den. Resultatet kan bli att serverprocessen stannar oväntat. Under vissa villkor kan den också leda till godtycklig kodkörning i serverprocessens kontext.

Enligt The Hacker News gäller risken en medlem i replikaset som har släpat efter och sedan blir primär, till exempel vid en failover. MongoDB har släppt korrigeringar. Sårbarheten finns inte med i CISA:s katalog över kända utnyttjade sårbarheter, och inga av källorna rapporterar attacker.

Vem som påverkas

• Påverkade: mongod-processer som körs som medlemmar i ett replikaset. Detta gäller replikaset för shards och replikaset för config servers i shardade kluster.
• Inte påverkade: fristående mongod-instanser som inte ingår i något replikaset.

Bristen kan utlösas före autentisering, så att slå på autentisering skyddar inte dig. Den största risken gäller medlemmar i replikaset som kan nås från otillförlitliga nätverk eller från många applikationsvärdar.

Vad du bör göra nu

1. Lista dina medlemmar i replikaset. Kontrollera på varje MongoDB-server om mongod körs som del av ett replikaset (se nästa avsnitt). Fristående instanser behöver inga brådskande åtgärder för denna CVE.
2. Hitta den korrigerade versionen för din release-serie. MongoDB-ärendet SERVER-138119 (länkat nedan) är en del av korrigeringen. Det anger korrigerade versioner 9.0.7, 8.3.16, 8.0.37, 7.0.48, 6.0.30, 5.0.35 och 4.4.32. Jämför med SERVER-138175 för att bekräfta versionen för din serie.
3. Säkerhetskopiera din konfiguration. Spara /etc/mongod.conf (eller motsvarande) och kontrollera att en aktuell säkerhetskopia av dina data finns.
4. Uppgradera en medlem i taget. Börja med de sekundära noderna. Uppgradera paketet (till exempel apt install mongodb-org eller dnf update mongodb-org), starta om mongod och vänta tills medlemmen visar SECONDARY igen i rs.status(). Kör sedan rs.stepDown() på den primära noden och uppgradera den sist. I shardade kluster uppgraderar du config server-replikasetet och alla shard-replikaset.
5. Begränsa nätverksåtkomst. Port 27017 (eller din anpassade port) ska bara vara nåbar från applikationsservrar och de andra klustermedlemmarna. Använd din brandvägg eller bindIp för att säkerställa detta, både nu och efter uppdateringen.
6. Håll utkik efter krascher. Kontrollera mongod-loggarna och din övervakning för oväntade omstarter, särskilt vid val och failover.

Så kontrollerar du om du påverkas

• Kontrollera versionen med mongod --version, eller i mongosh med db.version().
• Kontrollera medlemskap i replikaset i mongosh med db.hello().setName. Om ett namn returneras är instansen medlem i ett replikaset och påverkas tills den uppdateras. Om inget returneras och rs.status() anger att instansen inte körs med replikering är den en fristående instans och påverkas inte.
• För shardade kluster kör kontrollen på varje shard-medlem och varje config server-medlem.
• Om en medlem har en äldre version än den korrigerade versionen för sin release-serie, uppdatera den.

Källor

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