Kritische Sicherheitslücke in MongoDB braucht keine Anmeldung

Zwei Ping-Befehle ohne Anmeldung genügen, damit ein MongoDB-Server beim nächsten Wechsel des Primärknotens abstürzen kann. Der Hersteller bewertet die Sicherheitslücke CVE-2026-118383 mit 9,5 von 10 Punkten und hat sie am 10. November in sieben Versionsreihen geschlossen. Angriffe sind nach seinen Angaben nicht bekannt.

MongoDB hat den Fehler nach eigenen Angaben selbst entdeckt. Datadog Security Labs hat am 11. November im Labor gezeigt, wie ein zurückliegendes Mitglied eines Replica-Sets mit Version 8.0.34 beim Failover abstürzt und der Verbund ohne Primärknoten dasteht.^[1]

Warum stürzt der Server erst beim Failover ab?

Der Angriff braucht zwei Schritte. Der erste fällt nicht auf: Ein Client ohne Konto schickt zwei Ping-Befehle mit einem readConcern.afterOpTime-Wert. Jeder Befehl legt im Server eine wartende Benachrichtigung an, einen sogenannten Waiter. Diese Waiter verschwinden nicht von selbst, sondern erst nach einem Neustart, einem Rollback oder wenn das Mitglied als Primärknoten abtritt.^[1]

Den zweiten Schritt liefert der Betrieb. Fällt das präparierte Mitglied hinter die anderen zurück und gewinnt später eine Wahl, läuft beim Abschluss des Aufholens die Aufräumroutine zweimal über denselben, schon freigegebenen Speicher (Use-after-free). Der neue Primärknoten bricht ab, bevor er eine Schreibanfrage annimmt.^[1][2] Der Patch beschränkt afterOpTime deshalb auf Systemnutzer und verhindert zusätzlich das doppelte Aufräumen.^[1]

Die Einstufung 9,5 klingt dramatischer, als der Laborbefund hergibt. Der Vektor im Advisory nennt eine hohe Angriffskomplexität, weil der Angreifer das Zurückfallen und die Wahl nicht selbst herbeiführen kann.^[2] Datadog erreichte keine Codeausführung, MongoDB hält sie unter bestimmten Bedingungen für möglich.^[1]

Als Muster passt die Sicherheitslücke zu MongoBleed (CVE-2025-14847) vom Dezember 2025: Auch dort ließ sich MongoDB ohne Anmeldung angreifen. Auch dort ging es um den Speicher des Serverprozesses. CISA nahm MongoBleed am 29. Dezember 2025 in den Katalog bereits ausgenutzter Lücken auf.^[3] Wie lange diesmal zwischen Patch und erstem Angriff liegt, ist offen. Bei der Apache-Lücke im HTTP/2-Modul vom selben Tag war die Lage ähnlich.

Was sollten MongoDB-Betreiber jetzt tun?

• Version prüfen: Fragen Sie auf jedem Mitglied die laufende Version ab, auch bei Containern und bei Servern, die während der Wartung offline waren. Heben Sie sie auf die erste sichere Version der Reihe.^[1]
• Zugriff beschränken: Erreichbar sein sollte MongoDB nur für die Systeme, die es brauchen. Das verhindert die Pings nicht ganz, begrenzt aber, wer sie senden kann.^[1]
• Logs durchsuchen: Gesucht werden Slow-Query-Einträge (ID 51803) mit Ping und afterOpTime sowie zwei Austritte aus dem Aufholen (ID 21363) in einem Wechsel. Eine normale Wahl allein ist kein Hinweis.^[1]
• Atlas-Wartung nicht aufschieben: MongoDB aktualisiert Atlas-Cluster in der Wartung. Haben Sie die Wartung verschoben, holen Sie das Update nach.^[1]

Agenturen und Hoster, die MongoDB für Kunden betreiben, beginnen bei den Replica-Sets mit Zugang aus anderen Netzen. Fällt die Datenbank eines Shops oder einer Plattform aus, trifft das nicht nur die IT: Betrifft das Unternehmen die NIS2-Richtlinie, gehört der Umgang mit Schwachstellen zu den Pflichtmaßnahmen (Art. 21 Abs. 2).^[4] Wie leicht ein Datenbankzugang zum Generalschlüssel wird, zeigte zuletzt CosmosEscape in Azure Cosmos DB.

FAQ: MongoDB-Sicherheitslücke CVE-2026-118383

Quellen

Mehr Newshunger?

• MongoDB CVE-2026-8053: Wenn die Datenbank zur Falle wird
• Apache HTTP Server: Kritische Sicherheitslücke im HTTP/2-Modul
• Kritische Sicherheitslücke in FortiManager und FortiAnalyzer
• CosmosEscape in Azure Cosmos DB: Ein Generalschlüssel öffnete jede Datenbank
• GhostLock: Eine Stack-Use-after-free steckte 15 Jahre in fast jedem Linux-Kernel
• Modern Events Calendar: Abonnenten konnten Buchungen und Datenbank auslesen