Kritische MongoDB-Lücke kann Replica-Set-Mitglieder beim Failover abstürzen lassen
Eine kritische Schwachstelle in MongoDB Server kann ein Replica-Set-Mitglied nach einem späteren Failover zum Absturz bringen. TheHackerNews berichtete am 12. November, dass ein nicht authentifizierter Angreifer dafür zwei Anfragen senden muss. Betroffen sind Mitglieder von Replica Sets sowie Shard- und Config-Server-Mitglieder in geshardeten Clustern; ein einzelner mongod außerhalb eines Replica Sets ist laut dem Bericht nicht betroffen.
Die Lücke trägt die Kennung CVE-2026-118383 und erhielt laut MongoDB eine Bewertung von 9,5 von 10 nach CVSS 4.0. Datadog Security Labs reproduzierte den Absturz in einem Labor. Die Ursache ist ein Use-after-free: Der Server verwendet Speicher weiter, den er bereits freigegeben hat. MongoDB teilte laut dem Bericht mit, dass dem Unternehmen keine Ausnutzungsversuche bekannt seien.
Der Angreifer setzt die Schwachstelle über Ping-Anfragen mit dem Feld readConcern.afterOpTime in Gang. Diese Anfragen hinterlegen Wartemeldungen, die bei einem späteren Aufholvorgang nach der Wahl eines neuen Primärmitglieds zweimal bereinigt werden können. Laut Datadog muss der Angreifer weder Schreibzugriff noch Zugangsdaten besitzen, kann den Rückstand des Zielmitglieds oder die Wahl aber nicht selbst erzwingen.
MongoDB hat laut dem Bericht bereits korrigierte Versionen veröffentlicht. In der 8.0-Reihe weist Version 8.0.37 die Anfragen als nicht autorisiert zurück; Version 8.0.34 stürzte im Labortest mit einem Segmentation Fault ab. Die Reparatur verhindert außerdem, dass die Bereinigung zweimal läuft. MongoDB sagte, die Schwachstelle könne unter bestimmten Bedingungen auch zur Ausführung beliebigen Codes im Serverprozess führen; Datadog erreichte im eigenen Test jedoch keine Codeausführung.
Betreiber selbst verwalteter Installationen sollten laut MongoDB die feste Version auf jedem Replica-Set-Mitglied einspielen. Das umfasst auch Mitglieder in Containern und Systeme, die während eines Wartungsfensters offline waren. Bis zur Aktualisierung empfehlen die Forscher, den Netzwerkzugriff auf die Datenbank auf die Systeme zu beschränken, die ihn benötigen. Diese Maßnahme begrenzt die möglichen Absender der Anfragen, beseitigt die Schwachstelle aber nicht.
Für die Suche nach einem Angriff nennt Datadog mehrere Loghinweise: einen nicht authentifizierten Ping mit readConcern.afterOpTime und MaxTimeMSExpired, gefolgt von einem Übergang in den Primary-Catch-up und zwei Austritten aus diesem Zustand. Ein Fatal Signal oder Backtrace mit CatchupState::abort_inlock() nach diesen Ereignissen kann den Verdacht erhärten. Die Forscher weisen darauf hin, dass die relevanten Anfragefelder nur abhängig von den Logging-Einstellungen sichtbar sind.