MongoDB schließt kritische Lücke in Replica Sets

MongoDB hat eine kritische Sicherheitslücke in seinem Datenbankserver geschlossen, über die Angreifer ohne Anmeldung einen Server zum Absturz bringen können. Die Schwachstelle CVE-2026-118383 ist mit einem CVSS-4.0-Wert von 9,5 bewertet. Unter bestimmten Bedingungen kann sie laut MongoDB auch das Ausführen von Code im Serverprozess ermöglichen. Das Unternehmen hat die Lücke nach eigenen Angaben selbst gefunden und Anfang der Woche korrigierte Versionen veröffentlicht. Es habe „keine Kenntnis von Versuchen, diese Schwachstelle auszunutzen“.

Absturz nach der Wahl zum Primary

Betroffen sind Mitglieder eines Replica Sets, also einer Gruppe von MongoDB-Servern, die Kopien derselben Daten vorhalten, einschließlich der Shard- und Config-Server in Sharded Clustern. Einzelne Server außerhalb eines Replica Sets sind nicht betroffen. Ein Mitglied, der Primary, nimmt alle Schreibvorgänge an, die anderen replizieren sie. Fällt der Primary aus, wählen die übrigen Mitglieder einen neuen.

Laut einer Analyse von Datadog Security Labs genügen zwei Ping-Befehle mit dem Parameter readConcern.afterOpTime, um auf einem Mitglied sogenannte Waiter zu hinterlegen. Das allein führt noch nicht zum Absturz. Wird dieses Mitglied jedoch später zum neuen Primary gewählt, obwohl ihm noch Änderungen fehlen, läuft beim Abschluss des Nachholvorgangs eine Bereinigung zweimal ab.

Dabei wird bereits freigegebener Speicher erneut verwendet (Use-after-free), und der neue Primary stürzt ab, bevor er Schreibvorgänge annimmt. Aktivierte Authentifizierung verhindert das bei anfälligen Versionen nicht. Angreifer können allerdings weder selbst dafür sorgen, dass ein Mitglied zurückfällt oder eine Wahl gewinnt, noch erkennen, wann das geschieht. In ihren Tests erreichten die Forscher keine Codeausführung.

Alle Mitglieder aktualisieren

Für jeden betroffenen Versionszweig gibt es eine korrigierte Version, für den Zweig 8.0 etwa 8.0.37. In der korrigierten Version dürfen nur Systembenutzer readConcern.afterOpTime verwenden. Cluster im Cloud-Dienst MongoDB Atlas erhalten die Korrekturen automatisch bei der Wartung. Wer Wartungen aufschiebt, sollte sie vorziehen. Bei selbst betriebenen Installationen muss jedes Mitglied eines Replica Sets aktualisiert werden, auch in Containern und solche, die während der Wartung offline waren. Der Zweig 8.2 wird nicht als betroffen aufgeführt, hat aber am 31. Juli das Ende seiner Unterstützung erreicht. Laut einem Proof of Concept zeigte auch die Version 8.2.12 in einem Labortest den Fehler.

Bis zum Update raten die Forscher, den Netzwerkzugriff auf die Datenbank auf die nötigen Systeme zu beschränken. Hinweise auf Angriffe liefern laut Datadog unter anderem Protokolleinträge zu langsamen Anfragen mit der ID 51803 für nicht angemeldete Pings mit readConcern.afterOpTime sowie ein zweimaliges Verlassen des Nachholvorgangs mit der ID 21363 bei einem einzigen Wechsel zum Primary.

(red)