MongoDB-replicaset: pre-auth use-after-free kan servers laten crashen (CVE-2026-118383)

Wat er is gebeurd

Op 10 november 2026 heeft MongoDB CVE-2026-118383 gemeld, een use-after-free in de replicatiecomponent van MongoDB Server. De kwetsbaarheid heeft een CVSS-score van 9.0. De fout kan optreden wanneer een nieuw gekozen primary van een replicaset de inhaalslag afrondt. Verzoeken die geen authenticatie vereisen, kunnen dit activeren. Het gevolg kan zijn dat het serverproces onverwacht stopt. Onder bepaalde voorwaarden kan het ook leiden tot willekeurige codeuitvoering in de context van het serverproces.

Volgens The Hacker News betreft het risico een lid van een replicaset dat achterliep en vervolgens primary werd, bijvoorbeeld tijdens een failover. MongoDB heeft fixes uitgebracht. De kwetsbaarheid staat niet in de catalogus van bekende actief misbruikte kwetsbaarheden van CISA, en geen van de bronnen meldt aanvallen.

Wie is getroffen

• Getroffen: mongod-processen die als lid van een replicaset draaien. Dit omvat de shard-replicasets en config-serverreplicasets van gesharde clusters.
• Niet getroffen: losstaande mongod-instanties die geen onderdeel zijn van een replicaset.

De fout kan vóór authenticatie worden getriggerd, dus het inschakelen van authenticatie beschermt u niet. Het hoogste risico loopt een lid van een replicaset dat bereikbaar is vanuit onbetrouwbare netwerken of vanaf veel applicatiehosts.

Wat u nu moet doen

1. Maak een lijst van uw replicasetleden. Controleer op elke MongoDB-server of mongod als onderdeel van een replicaset draait (zie de volgende sectie). Losstaande instanties hoeven voor deze CVE niet direct te worden aangepakt.
2. Zoek de gefixte versie voor uw release-reeks. Het MongoDB-ticket SERVER-138119 (hieronder gelinkt) maakt deel uit van de fix. Het noemt de fixversies 9.0.7, 8.3.16, 8.0.37, 7.0.48, 6.0.30, 5.0.35 en 4.4.32. Vergelijk dit met SERVER-138175 om de versie voor uw reeks te bevestigen.
3. Maak een back-up van uw configuratie. Bewaar /etc/mongod.conf (of uw equivalent) en controleer of er een recente back-up van uw gegevens bestaat.
4. Update één lid tegelijk. Begin met de secondaries. Werk het pakket bij (bijvoorbeeld apt install mongodb-org of dnf update mongodb-org), herstart mongod en wacht tot het lid in rs.status() weer SECONDARY aangeeft. Voer daarna rs.stepDown() uit op de primary en update die als laatste. Werk in gesharde clusters eerst de config-serverreplicaset bij en vervolgens elke shard-replicaset.
5. Beperk de netwerktoegang. Poort 27017 (of uw aangepaste poort) mag alleen bereikbaar zijn vanaf applicatieservers en de andere clusterleden. Gebruik uw firewall of bindIp om dit af te dwingen, zowel nu als na de update.
6. Let op crashes. Controleer de mongod-logs en uw servicemonitoring op onverwachte herstarts, vooral rond verkiezingen en failovers.

Zo controleert u of u getroffen bent

• Controleer de versie met mongod --version, of in mongosh met db.version().
• Controleer het lidmaatschap van de replicaset in mongosh met db.hello().setName. Als er een naam wordt teruggegeven, is de instantie een lid van een replicaset en is deze getroffen totdat deze is bijgewerkt. Als er niets wordt teruggegeven en rs.status() meldt dat de instantie niet met replicatie draait, is het een losstaande instantie en is deze niet getroffen.
• Voer voor gesharde clusters de controle uit op elk shardlid en elk config-serverlid.
• Als een lid een oudere versie heeft dan de gefixte versie voor de release-reeks, werk het dan bij.

Bronnen

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