MongoDB: Kritische Lücke CVE-2026-118383 lässt Replica Sets beim Failover abstürzen

MongoDB hat eine kritische Sicherheitslücke in MongoDB Server geschlossen. CVE-2026-118383 erlaubt es einem Angreifer ohne Zugangsdaten, mit zwei harmlos aussehenden Anfragen einen Absturz vorzubereiten. Der Absturz passiert allerdings erst, wenn der angegriffene Server später unter bestimmten Bedingungen zum neuen Hauptserver gewählt wird. MongoDB bewertet die Lücke mit 9,5 von 10 Punkten (CVSS 4.0). Betroffen sind Replica Sets, also fast jede produktive MongoDB-Installation. Updates gibt es für alle unterstützten Versionszweige.

Das Wichtigste in Kürze

• Lücke: CVE-2026-118383, ein Use-after-free im Replikations-Code von MongoDB Server. CVSS 4.0: 9,5 (kritisch).
• Betroffen: Mitglieder von Replica Sets, auch Shards und Config-Server in Sharded Clusters. Ein einzelner mongod ohne Replica Set ist nicht betroffen.
• Angriff: zwei unauthentifizierte ping-Befehle. Aktivierte Authentifizierung schützt auf verwundbaren Versionen nicht.
• Folge: Absturz des neuen Primary nach einem Failover. MongoDB hält unter bestimmten Bedingungen auch Codeausführung für möglich.
• Fix: 9.0.7, 8.3.16, 8.0.37, 7.0.48, 6.0.30, 5.0.35 oder 4.4.32. Atlas wird automatisch aktualisiert.
• Angriffe bekannt? Laut MongoDB nein. Die Lücke wurde intern gefunden.

Was ist passiert?

MongoDB hat die Lücke am 10. November 2026 im eigenen Community-Forum bekannt gegeben und gleichzeitig korrigierte Versionen veröffentlicht. Laut Hersteller wurde der Fehler durch das eigene Sicherheitsprogramm entdeckt, Angriffe seien nicht bekannt. Einen Tag später haben Forscher von Datadog Security Labs eine technische Analyse veröffentlicht und den Absturz im Labor nachgestellt. The Hacker News hat am 12. November darüber berichtet.

Wie der Angriff funktioniert

Ein Replica Set besteht aus mehreren MongoDB-Servern mit denselben Daten. Einer ist der Primary und nimmt alle Schreibzugriffe an, die anderen (Secondaries) kopieren sie. Fällt der Primary aus, wählen die übrigen einen neuen. Hinkt der Gewinner etwas hinterher, holt er die fehlenden Schreibvorgänge zuerst nach („Catch-up“). Genau in den Aufräumarbeiten am Ende dieses Catch-ups steckt der Fehler.

Der Ablauf nach der Analyse von Datadog:

• Vorbereitung: Der Angreifer schickt zwei ping-Befehle mit dem Feld readConcern.afterOpTime an ein erreichbares Mitglied. Verwundbare Server nehmen ping schon vor der Anmeldung an. Der Server legt für jede Anfrage einen „Waiter“ an, eine wartende Benachrichtigung. Die laufen nicht ab und bleiben, bis der Server neu startet, ein Rollback macht oder als Primary zurücktritt.
• Auslöser: Später gewinnt genau dieses Mitglied eine Wahl, obwohl es hinter einem anderen zurückliegt. Das kann der Angreifer weder erzwingen noch beobachten, das passiert etwa bei Wartung oder Ausfällen.
• Absturz: Am Ende des Catch-ups läuft die Aufräumroutine zweimal und greift auf bereits freigegebenen Speicher zu. Der neue Primary stürzt ab, bevor er Schreibzugriffe annimmt.

Im Labor stürzte Version 8.0.34 mit einem Segmentation Fault ab, das Testcluster stand danach ohne Primary da. Codeausführung haben die Forscher nicht erreicht. Die korrigierte Version 8.0.37 lehnte die beiden Anfragen sofort als nicht autorisiert ab. Laut den Jira-Tickets besteht der Fix aus zwei Teilen: Nur noch Systembenutzer dürfen readConcern.afterOpTime verwenden (SERVER-138119), und die Aufräumroutine läuft nicht mehr doppelt (SERVER-138175).

Betroffene und korrigierte Versionen

Betroffen ist jeweils jede Version eines Zweigs vor der korrigierten Version. Angaben laut CVE-Eintrag:

Der Zweig 8.2 steht nicht auf der Liste. Er hat laut MongoDB am 31. Juli 2026 sein Supportende erreicht und bekommt keine Sicherheitsupdates mehr. Ein auf GitHub veröffentlichter Proof of Concept meldet, dass auch 8.2.12 im Labortest den Fehler zeigte, allerdings mit einer Testeinstellung, die ein Angreifer von außen nicht setzen kann. Wer noch 8.2 betreibt, sollte auf 8.3.16 oder 9.0.7 wechseln.

Was Admins jetzt tun sollten

1. Version prüfen. Auf jedem Mitglied des Replica Sets, auch in Containern und auf Servern, die während der Wartung offline waren:

mongod --version
# oder in der mongosh:
db.version()

2. Aktualisieren. Unter Debian und Ubuntu mit dem offiziellen MongoDB-Repository reicht in der Regel:

sudo apt update
sudo apt install --only-upgrade mongodb-org
sudo systemctl restart mongod

Unter RHEL, Rocky oder Alma entsprechend sudo dnf upgrade mongodb-org. Bei Docker das Image mit der korrigierten Version ziehen (zum Beispiel mongo:8.0.37) und den Container neu erstellen. Im Replica Set wie üblich rollierend aktualisieren: erst die Secondaries nacheinander, dann den Primary mit rs.stepDown() zurücktreten lassen und zuletzt aktualisieren.

3. MongoDB Atlas: Hier spielt MongoDB die Updates im Wartungsfenster automatisch ein. Wer Wartungen aufschiebt, sollte sie jetzt ausführen.

4. Bis zum Update: Den Netzwerkzugriff auf Port 27017 auf die Systeme beschränken, die ihn wirklich brauchen (Firewall, Security Groups, kein Zugriff aus dem Internet). Das ist ein Rat der Datadog-Forscher, kein offizieller Workaround von MongoDB, und behebt die Lücke nicht.

Logs auf Spuren prüfen

Datadog nennt drei Hinweise in den strukturierten MongoDB-Logs:

• Ein „Slow query“-Eintrag (ID 51803) für einen unauthentifizierten ping mit readConcern.afterOpTime, der mit MaxTimeMSExpired endet.
• Ein Mitglied tritt in den Catch-up ein (ID 21359) und verlässt ihn in derselben Wahl zweimal (ID 21363).
• Danach ein fatales Signal oder ein Backtrace mit CatchupState::abort_inlock().

Eine normale Wahl oder ein einzelnes Catch-up-Ende sind kein Hinweis. Die Anfragen können lange vor dem Failover gekommen sein, also auch ältere Logs prüfen. Das Feld attr.remote zeigt unter Umständen nur eine Loopback-Adresse statt der echten Client-IP.

Einordnung

Die Lücke ist kritisch bewertet, aber kein Selbstläufer für Angreifer: Sie brauchen Netzwerkzugang zur Datenbank und müssen auf einen Failover mit nachhängendem Mitglied warten, den sie nicht sehen. Gefährlich ist sie trotzdem, weil Authentifizierung nicht schützt und die vorbereiteten „Waiter“ unbemerkt liegen bleiben. Das Update ist bei allen Zweigen ein Patch-Release und sollte sich problemlos einspielen lassen. Wer MongoDB direkt aus dem Internet erreichbar betreibt, hat ohnehin ein größeres Problem und sollte das bei dieser Gelegenheit ändern.

Häufige Fragen

Bin ich mit einem einzelnen MongoDB-Server betroffen?

Nein. Ein Standalone-mongod außerhalb eines Replica Sets ist laut MongoDB nicht betroffen. Viele Anwendungen und Container-Setups starten MongoDB aber als Replica Set mit nur einem Mitglied, etwa für Change Streams oder Transaktionen. Formal ist das dann ein Replica Set. Weil es dort keine Wahl mit einem nachhängenden Mitglied gibt, ist der beschriebene Absturz nach meiner Einschätzung kaum auslösbar. Aktualisieren solltest du trotzdem.

Schützt die Authentifizierung vor CVE-2026-118383?

Nein. Verwundbare Versionen nehmen den ping-Befehl schon vor der Anmeldung an. Erst der Fix beschränkt afterOpTime auf Systembenutzer.

Wird die Lücke bereits ausgenutzt?

MongoDB sind keine Angriffe bekannt (Stand 10. November 2026). Ein Proof of Concept ist aber öffentlich.

Quellen

• The Hacker News: Critical Pre-Auth MongoDB Flaw (CVE-2026-118383) Can Crash Lagging Servers on Failover
• MongoDB Community Hub: Important MongoDB security update available (10.11.2026)
• Datadog Security Labs: CVE-2026-118383 – Use-after-free vulnerability in MongoDB
• MongoDB: Release Notes 8.3.16
• CVE.org: CVE-2026-118383