Eine schwerwiegende Schwachstelle im MongoDB Server bringt Zehntausende Datenbanken in Gefahr, da Angreifer ohne Authentifizierung aus der Ferne vertrauliche Daten direkt aus dem Datenbankspeicher abziehen können.
Die als MongoBleed bezeichnete Schwachstelle wurde aufgrund ihrer Fähigkeit, aus betroffenen Systemen verbleibende Speicherinhalte „ausbluten“ zu lassen, mit Heartbleed verglichen.
Die Schwachstelle „… ermöglicht es nicht authentifizierten Angreifern aus der Ferne, nicht initialisierten Heap-Speicher aus MongoDB-Serverinstanzen auszulesen“, sagten Censys-Forscher.
Die MongoBleed-Schwachstelle zur Offenlegung von Speicherinhalten
MongoBleed (CVE-2025-14847) ist eine Schwachstelle zur Offenlegung nicht initialisierten Speichers in der Implementierung der zlib-Dekomprimierung von Nachrichten durch MongoDB Server.
Wenn eine MongoDB-Instanz eine speziell präparierte komprimierte Nachricht verarbeitet, kann ein Logikfehler in der Dekomprimierungsroutine dazu führen, dass der Server Fragmente des Heap-Speichers zurückgibt, die vor ihrer Rücksendung an den Anfragenden nie ausdrücklich initialisiert wurden.
Heap-Speicher wird von der Datenbank dynamisch zugewiesen und wiederverwendet, um laufende Vorgänge wie die Verarbeitung von Abfragen, Authentifizierungsabläufe und die Sitzungsverwaltung zu bewältigen.
Daher können die offengelegten Speicherinhalte Restdaten aus vorherigen Anfragen enthalten und möglicherweise hochsensible Artefakte wie Klartext-Zugangsdaten, Authentifizierungsschlüssel, Sitzungstoken oder personenbezogene Daten (PII) preisgeben, die die Datenbank kürzlich verarbeitet hat.
Besonders bedenklich an MongoBleed ist die niedrige Einstiegshürde für eine Ausnutzung.
Die Schwachstelle kann ohne Authentifizierung ausgelöst werden. Das bedeutet, dass jeder entfernte Akteur mit Zugriff auf den MongoDB-Serviceport auf Netzwerkebene einen Ausnutzungsversuch starten kann.
Angreifer benötigen weder gültige Zugangsdaten noch vorherigen Zugriff auf das System, wodurch sich die potenzielle Angriffsfläche vergrößert.
Das Risiko wird durch die standardmäßigen MongoDB-Konfigurationen noch verstärkt.
Die zlib-Komprimierung ist in Standardbereitstellungen standardmäßig aktiviert. Daher waren viele Instanzen unmittelbar nach der Offenlegung gefährdet, sofern Administratoren die Komprimierung nicht ausdrücklich deaktiviert oder den Netzwerkzugriff eingeschränkt hatten.
In Umgebungen, in denen MongoDB-Instanzen direkt aus dem öffentlichen Internet erreichbar sind, können Ausnutzungsversuche in großem Maßstab automatisiert werden.
Zudem gibt es Berichte über eine aktive Ausnutzung in freier Wildbahn sowie einen Proof of Concept (PoC).
MongoDB gegen die Offenlegung von Speicherinhalten absichern
Um das durch MongoBleed entstehende Risiko zu bewältigen, sind sowohl eine zeitnahe Behebung als auch umfassendere Schutzmaßnahmen erforderlich.
- MongoDB sofort durch ein Upgrade auf korrigierte Versionen patchen, und nicht mehr unterstützte ältere Versionen ablösen.
- Die zlib-Komprimierung über die MongoDB-Konfiguration deaktivieren , wenn ein sofortiges Patchen nicht möglich ist, um eine Ausnutzung des anfälligen Dekomprimierungspfads zu verhindern.
- MongoDB-Instanzen in privaten Netzwerken platzieren, den Zugriff auf vertrauenswürdige IP-Bereiche beschränken und Datenbankbereitstellungen mit direkter Internetanbindung vermeiden.
- Durchsetzen der Authentifizierung, der rollenbasierten Zugriffskontrolle und der TLS-Verschlüsselung , um den Explosionsradius zu verringern und die Auswirkungen einer möglichen Datenoffenlegung zu begrenzen.
- Überwachen Sie Protokolle und Netzwerkverkehr auf ungewöhnliches Verbindungsverhalten, fehlerhaft formatierte Anfragen oder ungewöhnliche Antwortgrößen, die auf Ausnutzungsversuche hindeuten können.
- Datenbankzugangsdaten und vertrauliche Geheimnisse nach dem Patchen, und Konfigurationen durch kontinuierliche Erkennung von Assets und Überwachung der Angriffsfläche validieren.
In ihrer Gesamtheit verringern diese Maßnahmen den Explosionsradius und stärken langfristig die Widerstandsfähigkeit der Datenbanksicherheit.
MongoBleed verdeutlicht ein verbreitetes Infrastrukturproblem: Schwachstellen in der Speichersicherheit zentraler Komponenten werden durch Standardeinstellungen und die Erreichbarkeit aus dem öffentlichen Internet verschärft.
Die Bewältigung dieser Art von Risiko erfordert zunehmend, über perimeterbasierte Annahmen hinaus zu Zero-Trust-Ansätzen überzugehen, die den Zugriff kontinuierlich überprüfen und implizites Vertrauen minimieren.