- MongoBleed (CVE-2025-14847) ist eine schwerwiegende Memory-Leak-Schwachstelle, die seit 2017 in allen MongoDB-Versionen vorhanden war und es Angreifern ermöglicht, beliebige Daten aus dem Heap-Speicher der Datenbank zu lesen
- Die Schwachstelle entsteht durch einen Bug im zlib-Komprimierungspfad und kann ohne Authentifizierung ausgenutzt werden, indem man sich einfach mit der Datenbank verbindet
- Angreifer können manipulierte komprimierte Anfragen senden, um den Server dazu zu bringen, einen Puffer mit falscher Größe zu allokieren, wodurch Speicher früherer Vorgänge (Passwörter, API-Schlüssel usw.) offengelegt werden kann
- MongoDB hat am 19. Dezember 2025 einen Patch veröffentlicht, aber EOL-Versionen (3.6, 4.0, 4.2) wurden nicht korrigiert
- Diese 8 Jahre lang vorhandene Schwachstelle betrifft mehr als 210.000 dem Internet ausgesetzte MongoDB-Instanzen und erfordert in Cloud- wie auch On-Premises-Umgebungen sofortiges Patchen oder das Deaktivieren der Komprimierung
Überblick über MongoBleed
- MongoBleed (CVE-2025-14847) ist eine Schwachstelle im zlib-1-Nachrichtenkomprimierungspfad von MongoDB, die alle Versionen seit 2017 betrifft
- Angreifer können ohne Authentifizierung allein durch eine Verbindung zur Datenbank beliebige Heap-Speicherdaten lesen
- End-of-Life-(EOL)-Versionen wie MongoDB 3.6, 4.0 und 4.2 wurden nicht behoben
- Der Bug wurde durch einen PR im Mai 2017 eingeführt und am 19. Dezember 2025 offiziell veröffentlicht
- MongoDB erklärte, den Patch auf alle Instanzen einschließlich des Atlas-Cloud-Service angewendet zu haben
Kommunikationsstruktur von MongoDB
- MongoDB verwendet statt HTTP ein eigenes TCP-Protokoll, und Nachrichten werden im BSON-Format (Binary JSON) übertragen
- Alle Anfragen bestehen aus dem Befehl OP_MSG und werden bei Komprimierung in eine OP_COMPRESSED-Nachricht verpackt
- Die Nachricht enthält Felder wie
uncompressedSize, originalOpcode und compressorId
uncompressedSize gibt die erwartete Größe nach dem Dekomprimieren an
Exploit-Schritt 1 — Falsche Pufferallokation
- Angreifer setzen den Wert von
uncompressedSize auf einen übermäßig großen Wert, damit der Server einen großen Puffer allokiert
- Beispiel: Eine tatsächliche 1-KB-Nachricht wird als 1 MB deklariert
- Der MongoDB-Server vertraut nach dem Dekomprimieren der vom Benutzer angegebenen Größe, ohne die tatsächliche Größe zu validieren
- Dadurch bleibt im Speicher eine Struktur der Form
[tatsächliche Daten | nicht referenzierter Heap-Müll] zurück
- Da das auf C++ basierende MongoDB keine Speicherinitialisierung durchführt, können sich in diesem Bereich sensible Daten früherer Vorgänge befinden
- Beispiele: Passwörter, Session-Token, API-Schlüssel, Kundendaten, Systemeinstellungen usw.
Exploit-Schritt 2 — Datenabfluss
- Angreifer senden fehlerhafte BSON-Eingaben, um den Server dazu zu bringen, die Müll-Daten im Speicher als String zu parsen
- Das erste Feld in BSON ist ein String und folgt der Regel von nullterminierten Strings (null-terminated string) aus C
- Wenn Angreifer einen String ohne Nullterminator senden, liest der Server weitere Daten aus dem Speicher mit ein
- Beispiel:
[ { "a | password: 123\0 | apiKey: jA2sa | ip: 219.117.127.202 ]
- Der Server erkennt dies als ungültiges BSON-Feld und antwortet mit einer Fehlermeldung, die den betreffenden Inhalt enthält
"errmsg": "invalid BSON field name 'a | password: 123'"
- Durch Wiederholung dieses Vorgangs können Angreifer den gesamten Heap-Speicher scannen und sensible Informationen sammeln
Auswirkungen und Risiko
- Da dies in der Pre-Auth-Phase geschieht, können Angreifer ohne Anmeldung auf Daten zugreifen
- Dem Internet ausgesetzte MongoDB-Instanzen sind unmittelbar gefährdet
- Laut Shodan-Suche sind mehr als 213.000 MongoDB-Instanzen öffentlich erreichbar
- Die Schwachstelle bestand von 2017 bis 2025, also etwa 8 Jahre lang, und ist aufgrund ihrer einfachen Struktur wahrscheinlich realistisch ausnutzbar
- MongoDB erklärte, es gebe „bisher keine Hinweise auf Ausnutzung“, veröffentlichte jedoch keine offizielle Entschuldigung oder detaillierte Timeline
Gegenmaßnahmen
- Auf die neueste gepatchte Version (8.0.17 oder höher) aktualisieren
- Kurzfristig kann auch das Deaktivieren der zlib-Netzwerkkomprimierung die Gefahr mindern
- Bei Nutzern von MongoDB Atlas ist der Patch bereits eingespielt
Weitere Informationen und verwandte Diskussionen
- Der Lead des Elastic-Security-Teams gab der Schwachstelle den Namen „MongoBleed“ und veröffentlichte einen PoC (Python-Skript)
- MongoDB und Elastic stehen im Bereich Suche und Analysefunktionen in einem Wettbewerbsverhältnis
- Verwandte Ressourcen:
Zusammenfassung
- MongoBleed ist eine Memory-Leak-Schwachstelle, die durch einen Bug in der zlib-Komprimierungsverarbeitung verursacht wird
- Angreifer können über manipulierte komprimierte Anfragen frühere Speicherdaten (Passwörter, API-Schlüssel usw.) erlangen
- Alle MongoDB-Versionen von 2017 bis 2025 sind betroffen; Patchen oder das Deaktivieren der Komprimierung ist zwingend erforderlich
- Mehr als 210.000 öffentlich erreichbare Instanzen sind potenziell betroffen
- MongoDB hat zwar einen Patch veröffentlicht, doch die fehlende Unterstützung für EOL-Versionen und die verzögerte öffentliche Reaktion werden kritisiert
Noch keine Kommentare.