MongoDB-Replica-Sets: Use-after-free vor der Authentifizierung kann Server zum Absturz bringen (CVE-2026-118383)

Was geschehen ist

Am 10. November 2026 hat MongoDB die Schwachstelle CVE-2026-118383 veröffentlicht, ein Use-after-free in der Replikationskomponente von MongoDB Server. Sie wird mit 9.0 nach CVSS bewertet. Die Schwachstelle kann auftreten, wenn ein neu gewählter Replica-Set-Primary den Aufholvorgang abschließt. Anfragen, die keine Authentifizierung benötigen, können sie auslösen. Die Folge kann sein, dass der Serverprozess unerwartet beendet wird. Unter bestimmten Bedingungen kann sie außerdem zur Ausführung beliebigen Codes im Kontext des Serverprozesses führen.

Laut The Hacker News besteht das Risiko für ein Replica-Set-Mitglied, das zurückgefallen ist und dann zum Primary wird, etwa bei einem Failover. MongoDB hat Korrekturen veröffentlicht. Die Schwachstelle ist nicht im Katalog bekannter ausgenutzter Schwachstellen der CISA aufgeführt, und keine der Quellen berichtet von Angriffen.

Wer betroffen ist

• Betroffen: mongod-Prozesse, die als Mitglieder eines Replica Sets laufen. Dazu gehören die Shard-Replica-Sets und die Config-Server-Replica-Sets von Sharded Clusters.
• Nicht betroffen: eigenständige mongod-Instanzen, die nicht Teil eines Replica Sets sind.

Die Schwachstelle kann vor der Authentifizierung ausgelöst werden. Die Aktivierung der Authentifizierung schützt Sie daher nicht. Das größte Risiko besteht für Replica-Set-Mitglieder, die aus nicht vertrauenswürdigen Netzwerken oder von vielen Anwendungshosts erreichbar sind.

Was Sie jetzt tun sollten

1. Replica-Set-Mitglieder erfassen. Prüfen Sie auf jedem MongoDB-Server, ob mongod als Teil eines Replica Sets läuft (siehe nächster Abschnitt). Eigenständige Instanzen benötigen für diese CVE keine dringende Maßnahme.
2. Korrigierte Version für Ihre Release-Reihe ermitteln. Das MongoDB-Ticket SERVER-138119 (unten verlinkt) ist Teil der Korrektur. Es nennt die korrigierten Versionen 9.0.7, 8.3.16, 8.0.37, 7.0.48, 6.0.30, 5.0.35 und 4.4.32. Vergleichen Sie dies mit SERVER-138175, um die Version für Ihre Reihe zu bestätigen.
3. Konfiguration sichern. Sichern Sie /etc/mongod.conf (oder Ihre entsprechende Datei) und stellen Sie sicher, dass ein aktuelles Backup Ihrer Daten vorhanden ist.
4. Jeweils ein Mitglied nach dem anderen aktualisieren. Beginnen Sie mit den Secondarys. Aktualisieren Sie das Paket (zum Beispiel apt install mongodb-org oder dnf update mongodb-org), starten Sie mongod neu und warten Sie, bis das Mitglied in rs.status() wieder als SECONDARY angezeigt wird. Führen Sie danach rs.stepDown() auf dem Primary aus und aktualisieren Sie ihn zuletzt. Aktualisieren Sie in Sharded Clusters das Config-Server-Replica-Set und jedes Shard-Replica-Set.
5. Netzwerkzugriff einschränken. Port 27017 (oder Ihr individueller Port) sollte nur von Anwendungsservern und den anderen Clustermitgliedern erreichbar sein. Setzen Sie Ihre Firewall oder bindIp ein, um dies durchzusetzen, sowohl jetzt als auch nach dem Update.
6. Auf Abstürze achten. Prüfen Sie die mongod-Logs und Ihr Service-Monitoring auf unerwartete Neustarts, besonders bei Wahlen und Failovers.

So prüfen Sie, ob Sie betroffen sind

• Prüfen Sie die Version mit mongod --version oder in mongosh mit db.version().
• Prüfen Sie die Replica-Set-Zugehörigkeit in mongosh mit db.hello().setName. Wird ein Name zurückgegeben, ist die Instanz ein Replica-Set-Mitglied und bis zur Aktualisierung betroffen. Wird nichts zurückgegeben und meldet rs.status(), dass die Instanz nicht mit Replikation läuft, handelt es sich um eine eigenständige Instanz, die nicht betroffen ist.
• Bei Sharded Clusters führen Sie die Prüfung auf jedem Shard-Mitglied und jedem Config-Server-Mitglied durch.
• Wenn ein Mitglied eine ältere Version als die korrigierte Version seiner Release-Reihe nutzt, aktualisieren Sie es.

Quellen

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