Eine kurze Erklärung der MongoBleed-Schwachstelle

 (bigdata.2minutestreaming.com)
2 Punkte von GN⁺ 2025-12-30 | 1 Kommentare | Auf WhatsApp teilen
  • 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

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

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-12-30
Hacker-News-Kommentare
  • Vor ein paar Jahren habe ich den Memory Allocator der Cloudflare-Workers-Runtime geändert, sodass beim Freigeben jeder Speicher mit einem festen Byte-Muster überschrieben wird.
    Dadurch bleiben in nicht initialisiertem Speicher keine sinnvollen Daten mehr zurück.
    Ich hatte einen Performance-Einbruch erwartet, aber tatsächlich gab es überhaupt keine messbaren Auswirkungen.
    Ich finde, jeder, der speicherunsichere Sprachen verwendet, sollte das so machen. Auch dieser Mongo-Bug hätte sich auf diese Weise wohl abmildern lassen.
    • Aktuelle macOS-Versionen führen beim Freigeben von Speicher automatisch ein Zero-Out durch.
      Dadurch wird die Speicherkonpression effizienter, und im Durchschnitt verbessert sich die Performance sogar.
    • Unter FreeBSD bewirkt die Umgebungsvariable MALLOC_CONF=opt.junk=free, dass malloc dasselbe tut.
      Viele Implementierungen bieten so eine Funktion also bereits als Option an.
    • Ich finde, im Jahr 2025 sollten alle allgemeinen Allocator Speicher standardmäßig mit 0 initialisieren.
      Wenn mehr Performance nötig ist, kann man für bestimmte Zwecke eigene Custom-Allocator schreiben.
      Dann wären auch andere Optimierungen möglich, die mit dem System-Allocator nicht gehen.
    • OpenBSD füllt neu allozierten Speicher mit 0xdb und freigegebenen Speicher mit 0xdf.
      Dadurch lassen sich Use-Before-Initialization- und Use-After-Free-Bugs schnell finden.
      Das ist dort die Standardeinstellung.
    • Ich frage mich, ob das dem Aktivieren der Kernel-Option init_on_free=1 entspricht.
  • Der Autor scheint den internen Entwicklungsprozess von Mongo nicht gut gekannt zu haben.
    Mongo entwickelt zuerst in einem internen privaten Repository und überträgt Commits dann mit Copybara ins öffentliche Repository.
    Die Verwirrung um die Datumsangaben ist in diesem Prozess entstanden.
    • Das wusste ich auch nicht. Ich fand es seltsam, dass es keine PR-Reviews gab, aber jetzt ergibt das Sinn.
      Ich werde den Artikel aktualisieren und diesen Punkt sowie die Datumsdifferenz erklären.
  • Der Autor scheint die Timeline missverstanden zu haben.
    Unsere Atlas-Cluster waren schon einige Tage vor der Veröffentlichung der CVE aktualisiert.
    • Danke, ich habe den Artikel aktualisiert.
  • In Systemen wie Datenbanken ist Zeroing oder Poisoning beim Freigeben von Speicher eine gute Entscheidung.
    Heutzutage sollten die meisten Allocator das standardmäßig tun.
    Chris hat das bei Blink verbessert, und das Ergebnis hat sich dann in ganz Chromium verbreitet.
    Die zugehörigen Dokumente sind ebenfalls interessant.
    Chromium-Blogpost
    PartitionAlloc-Dokumentation
  • Ich frage mich, wie oft Mongo-Instanzen direkt im Internet exponiert sind.
    Bei SQL ist das selten, kommt aber gelegentlich vor.
    • Meiner Erfahrung nach ist der Daseinszweck von MongoDB „Faulheit“.
      Die Philosophie ist, dass man sich um Schema, Haltbarkeit, Lesen/Schreiben, Konnektivität und nichts davon kümmern muss.
      Deshalb überrascht es mich nicht, dass man sich auch nicht um Sicherheit kümmert.
    • Alle drei „ernsthaften“ Organisationen, die ich kenne, haben Mongo verwendet, um sich den Schema-Entwurf zu sparen.
      Diese Haltung führt zu einem „Hauptsache jetzt bequem“-Denken und endet dann bei Sicherheitsproblemen wie öffentlich erreichbaren DB-Instanzen.
    • Diese Meinungen wirken mir viel zu extrem.
      In der Praxis ist es üblich, SQL und NoSQL zusammen zu verwenden.
      NoSQL hat Stärken bei Hochverfügbarkeit für große Datenmengen, SQL eignet sich für relationale Datenspeicherung.
      iMessage oder auch das Matchmaking-System von EA nutzen zum Beispiel NoSQL.
      Am Ende braucht man beides. Es ist kein Konkurrenz-, sondern ein Ergänzungsverhältnis.
    • Laut Shodan-Suchergebnis sind 213.000 Mongo-Instanzen exponiert.
    • Wenn man einen SQL-Server exponiert, sind die Folgen noch gravierender.
      PostgreSQL kann zum Beispiel schon mit der Standardkonfiguration Rechte über das gesamte System erlangen.
      Deshalb kennen die meisten Leute die Risiken öffentlich erreichbarer SQL-Server ziemlich gut.
  • MongoDB erklärte am 24. Dezember, es gebe „keine Hinweise auf eine Ausnutzung der CVE“, aber man sollte nicht vergessen: „Keine Belege sind kein Beleg für Nichtexistenz.“
    • Was, findest du, hätten sie dann sagen sollen?
  • Ich verstehe nicht, warum man Mongo immer noch verwendet.
    • Replikation ist einfach, und es ist schneller als JSONB in Postgres.
      Ich persönlich würde es nicht verwenden, aber es gibt Fälle, in denen DynamoDB oder MongoDB technisch passend sind.
    • Es gibt auch den Witz, dass man es wegen „web scale“ benutzt.
      Passendes Video
    • Früher war NoSQL im Trend, aber am Ende ist es auf einfache Key-Value-Datenbanken hinausgelaufen.
    • Diese Argumentation ist zu aggressiv, um sie einfach zu akzeptieren.
  • Das erinnert mich an den Optimismus, dass die OWASP Top 10 die wichtigsten Schwachstellen schon lösen würden.
    Aber Buffer Overflows gibt es seit 2003 immer noch.
    • Im Endeffekt hat man damit allen eine Footgun in die Hand gedrückt.
      Solche Probleme werden sich ewig wiederholen, solange sie nicht auf Sprachebene verhindert werden.
      Mein Mitgefühl an die Mongo-Entwickler.
  • Jedes Mal, wenn ein Artikel über NoSQL erscheint, zeigt sich, dass viele „Entwickler“ nie mit großem Traffic gearbeitet haben.
    • Diesmal scheinst eher nur du das zu denken.
  • MongoDB war schon immer eher schlecht … wurde aber „webscale“ genannt.
    Ich finde, man sollte lieber ToroDB oder JSONB in PostgreSQL verwenden.