LONDON (IT BOLTWISE) – Eine kritische Sicherheitslücke in MongoDB Server kann einen Server bei einem späteren Failover zum Absturz bringen. Betroffen sind Mitglieder von Replica Sets und auch Teile von Sharded Clusters, wobei Authentifizierung die Gefährdung für die zwei entscheidenden Anfragen nicht zuverlässig stoppt. Der Fehler ist als Use-after-free (CVE-2026-118383) bewertet und hat bei CVSS 4.0 eine Einstufung von 9,5 erhalten. MongoDB liefert bereits behobene Versionen, empfohlen wird ein zeitnahes Upgrade und eine zusätzliche Netzwerkabsicherung bis dahin.
MongoDB schließt eine Sicherheitslücke, die in der Praxis vor allem dann gefährlich wird, wenn ein replizierter Knoten nach einem Ereignis die Rolle des Primärservers übernimmt. Laut der Meldung können Angreifer ohne Authentifizierung zwei spezielle Anforderungen senden, die in einer späteren Konstellation zu einem Crash führen. Entscheidend ist dabei nicht nur die Zugehörigkeit zu einem Replica Set, sondern auch der Zustand des betroffenen Mitglieds: Der Absturz tritt nur auf, wenn dieses Mitglied nach den Anfragen als neuer Hauptknoten ausgewählt wird, während es noch nicht alle „jüngsten“ Änderungen nachgeholt hat.
Technisch handelt es sich um ein Use-after-free: Der Server greift auf Speicher zu, der bereits freigegeben wurde. Die Kollision zwischen Replikations- und Aufräumlogik entsteht dem Bericht zufolge beim Cleanup, der nach dem Catch-up-Schritt ausgeführt wird, also dem Zeitraum, in dem ein nach einem Failover „hinterherlaufendes“ Mitglied erst nachholt und dann anschließend wieder als Primär Änderungen entgegennimmt. In der Darstellung der Datadog Security Labs reicht es sogar aus, Waiter zu „pflanzen“: Die zwei Anforderungen tragen Ping-Befehle mit einem readConcern.afterOpTime-Wert, der den Server veranlasst, auf einen bestimmten Replikationsstand zu warten. Das bloße Platzieren dieser Waiters führt zunächst nicht direkt zum Absturz; der kritische Moment kommt, wenn der Cleanup die betreffenden Strukturen zweimal durchläuft und dabei erneut auf bereits freigegebenen Speicher zugreift.
Für den Betrieb bedeutet das: Nicht jeder Failover ist automatisch ein Treffer, und die Zeitsteuerung allein wirkt nicht wie ein generisches Rennen gegen die Uhren. Laut der Beschreibung können Angreifer weder sicher erzwingen, dass das Zielmitglied gezielt zurückfällt oder eine Wahl gewinnt, noch können sie den genauen Zeitpunkt dieser Zustandswechsel zuverlässig beobachten. Trotzdem ist die Bedrohung real, weil die Konstellation aus „hinterherlaufendem Mitglied“ und späterer Wahl des Primärs genau in typischen Hochverfügbarkeits-Setups vorkommt. Besonders relevant sind auch Sharded Clusters: Betroffen sind demnach unter anderem die Shard- und Config-Server-Mitglieder. Ein einzelner mongod außerhalb eines Replica Sets gilt dagegen als nicht betroffen.
MongoDB bewertet die Lücke mit 9,5 von 10 Punkten auf der CVSS 4.0-Skala und hat bereits feste Versionen bereitgestellt. Für Self-managed Deployments gilt die in der Meldung betonte Konsequenz: Das Upgrade muss auf jedem Mitglied eines Replica Sets erfolgen, nicht nur auf einem „zufällig“ erreichbaren Knoten. Wer Wartungsfenster verschiebt, sollte den Angriffspfad bis zur Aktualisierung zusätzlich reduzieren, indem der Netzwerkzugriff auf die Datenbank strikt auf notwendige Systeme beschränkt wird. Das verhindert den beschriebenen Crash nicht als solchen, senkt aber drastisch die Wahrscheinlichkeit, dass überhaupt zwei unautorisierte Anforderungen injiziert werden können.
Im Detail wird die Wirksamkeit der Fixes an konkreten Versionen festgemacht: Für die betroffene 8.0-Reihe ist eine Bereinigung in 8.0.37 enthalten, wobei in einem Labortest die unberechtigten Anforderungen dort gleichzeitig abgelehnt wurden, während die Version 8.0.34 den Absturz mit einem Segmentation Fault zeigte. Neben der reinen Stabilisierung greift der Fix laut Bericht an zwei Stellen an: Ein Teil sorgt dafür, dass nur Systembenutzer readConcern.afterOpTime nutzen dürfen, wodurch der kritische Pfad für unautorisierte Waiter unterbunden wird. Der zweite Teil verhindert, dass der Cleanup in Situationen mit bereits gesetzten Waitern doppelt läuft, wodurch das zweite Use-after-free verhindert wird. Für die 8.2-Reihe ist die Lage differenziert: Die jüngste Veröffentlichung der 8.2-Linie (8.2.12) soll in einem Proof-of-Concept in einem Laborszenario noch sichtbar betroffen gewesen sein, wobei der Remote-Angreifer die für den zuverlässigen Nachweis nötige Test-Only-Konfiguration nicht setzen kann.
Für Security- und Betriebsteams liefert der Bericht auch konkrete Anzeichen zur Verifikation in Logs. In den vulnerable Läufen sollen demnach bestimmte „Slow query“-Einträge (mit COMMAND „Slow query“, ID 51803) auftauchen, die einen unautorisierte Ping mit readConcern.afterOpTime zeigen und mit „MaxTimeMSExpired“ enden. Zusätzlich wird eine Sequenz rund um den Catch-up-Zustand beschrieben: Ein Log-Eintrag „member entering primary catch-up“ (ID 21359), der danach zweimal das Verlassen dieses Zustands auslöst (ID 21363). Wenn anschließend ein fataler Signal- oder Backtrace-Hinweis im Zusammenhang mit CatchupState: : abort_inlock() erscheint, ist das ein starkes Indiz für die fehlerhafte Cleanup-Umgebung. Wichtig ist zugleich die Eingrenzung: Eine „normale“ Election oder ein einzelner Catch-up-Exit gilt nicht als typischer Marker, und Anfragen können auch bereits vor dem eigentlichen Failover eintreffen, weshalb frühere Logs desselben Mitglieds mit betrachtet werden sollten.
Unterm Strich liegt der Handlungsdruck weniger in der theoretischen Reichweite als in der praktischen Betriebsrealität von Replica Sets: Hochverfügbarkeit bedeutet, dass Failover und Replikationsnachholung regelmäßig stattfinden. Wer Wartungstermine verschiebt, sollte das Upgrade-Backlog priorisieren, die betroffenen Knoten systematisch identifizieren und nach dem Update die tatsächlich laufenden Versionen je Mitglied prüfen, einschließlich Container-Instanzen sowie Knoten, die während des Wartungsfensters offline waren. Gleichzeitig empfiehlt sich eine sofortige Netzwerkhärtung, damit der initiale unautorisierte Request-Pfad gar nicht erst entsteht. Damit reduziert sich das Risiko bis zur vollständigen Bereinigung auf ein Minimum – und genau dieser „Zwischenzustand“ ist es, den der Use-after-free-Fehler in dieser Lücke so besonders verwundbar macht.
🔥 Heutige Hot Deals bei Amazon: Bis zu 80% Rabatte!
🎉 Amazon Haul-Store für absolute Schnäppchenjäger!
- ★ 23-stufiges KI-Go-Training – Für Spieler mit Grundkenntnissen der Regeln – Entwickelt als intelligenter Trainingspartner passt sich die KI Spielern von 18K bis 9D an. Ideal für alle, die die Grundregeln bereits beherrschen und ihr Spiel verbessern möchten.
- IHR EMOTIONALER AI-BEGLEITER: Eiliko ist mehr als nur ein Anhänger, es ist ein charismatischer KI-Freund. Mit einem dynamischen LED-Bildschirm, der eine Vielzahl von animierten Gesichtern und Ausdrucksformen anzeigt, reagiert er auf Ihre Interaktionen mit einzigartiger Persönlichkeit und Charme.
- 【MEHR LEBEN FÜR DEINEN SCHREIBTISCH】 Lerne Eilik kennen – deinen kleinen Roboter-Freund mit Persönlichkeit. Mit liebevollen Animationen, ausdrucksstarken Reaktionen und spielerischen Interaktionen bringt Eilik mehr Freude in deinen Alltag. Ob auf dem Schreibtisch, im Büro oder am Nachttisch – Eilik wird schnell zu einem vertrauten Begleiter für besondere Momente.
- 【XL-Größe für gedeihende Pflanzen】Geben Sie Ihren Pflanzen den Raum, den sie verdienen! Unser verbessertes, großes 13,7 cm großes Design bietet Platz für Pflanzen mit einem Durchmesser von bis zu 8,9 cm und damit deutlich mehr Platz für Wurzelwachstum und Pflanzengesundheit im Vergleich zu kleineren, veralteten Modellen. Die Produktabmessungen betragen 13,6 x 13,6 x 13,2 cm und das Gerät wiegt nur 355 g.
- V28 Update - JETZT MIT NEUEN FUNKTIONEN! Als Reaktion auf das Ladeproblem von Loona haben wir das automatische Aufladen 2.0 verbessert. Diese Optimierung hilft Loona, die Ladewege in verschiedenen Szenarien zu erkennen und anzupassen, um die Erfolgsquote beim automatischen Aufladen zu erhöhen. Mobile Hotspots können sich mit Loona verbinden und überwinden WLAN-Einschränkungen, sodass Sie jederzeit und überall mit Loona interagieren können.
- Die besten Bücher rund um KI & Robotik!
- Die besten KI-News kostenlos per eMail erhalten!
- Zur Startseite von IT BOLTWISE® für aktuelle KI-News!
- IT BOLTWISE® kostenlos auf Patreon unterstützen!
- Aktuelle KI-Jobs auf StepStone finden und bewerben!
- Künstliche Intelligenz: Dem Menschen überlegen – wie KI uns rettet und bedroht | Der Neurowissenschaftler, Psychiater und SPIEGEL-Bestsellerautor von »Digitale Demenz«
Du hast einen wertvollen Beitrag oder Kommentar zum Artikel "MongoDB: Kritische Use-after-Free-Lücke kann bei Failover Server abstürzen" für unsere Leser?
#Sophos
#AmazonPrime
#Bestseller
Es werden alle Kommentare moderiert!
Für eine offene Diskussion behalten wir uns vor, jeden Kommentar zu löschen, der nicht direkt auf das Thema abzielt oder nur den Zweck hat, Leser oder Autoren herabzuwürdigen.
Wir möchten, dass respektvoll miteinander kommuniziert wird, so als ob die Diskussion mit real anwesenden Personen geführt wird. Dies machen wir für den Großteil unserer Leser, der sachlich und konstruktiv über ein Thema sprechen möchte.
Du willst nichts verpassen?
Du möchtest über ähnliche News und Beiträge wie "MongoDB: Kritische Use-after-Free-Lücke kann bei Failover Server abstürzen" informiert werden? Neben der E-Mail-Benachrichtigung habt ihr auch die Möglichkeit, den Feed dieses Beitrags zu abonnieren. Wer natürlich alles lesen möchte, der sollte den RSS-Hauptfeed oder IT BOLTWISE® bei Google News wie auch bei Bing News abonnieren.
Nutze die Google-Suchmaschine für eine weitere Themenrecherche: »MongoDB: Kritische Use-after-Free-Lücke kann bei Failover Server abstürzen« bei Google Deutschland suchen, bei Bing oder Google News!