ByteRay GmbH
Hopfenstraße 8
80335 München
z
z
z
z
i
i
z
z
Wir durchleuchten digitale
Risiken.
Sprechen Sie direkt mit einem Security-Engineer: unverbindlich, technisch, konkret.
Lieber gleich einen Termin?
Erstgespräch buchen
MongoBleed liest unauthentifiziert Arbeitsspeicher aus MongoDB-Servern aus, inklusive Zugangsdaten. Der Patch schließt die Lücke, klärt aber nicht, was bereits abgeflossen ist.
Unsere DFIR-Bereitschaft ist rund um die Uhr erreichbar — auch ohne bestehenden Vertrag.
+49 89 2000 7683Betroffen sind Sie nur, wenn alle drei Bedingungen zutreffen. Fällt eine weg, sind Sie es nicht.
// 1. Version prüfen
mongod --version
// 2. Aktive Kompressoren prüfen (mongosh, Adminrechte)
db.adminCommand({ getCmdLineOpts: 1 })Alternativ direkt in der Konfiguration nachsehen. Taucht zlib unter net.compression.compressors auf, ist die Vorbedingung erfüllt:
grep -A4 "compression" /etc/mongod.conf| Betroffene Version | Zielversion |
|---|---|
| MongoDB Server 3.6, 4.0, 4.2 (alle Versionen, End of Life) | Migration auf 4.4.30, 5.0.32, 6.0.27, 7.0.28, 8.0.17 oder 8.2.3 |
| 4.4.0 bis 4.4.29 | 4.4.30 oder neuer |
| 5.0.0 bis 5.0.31 | 5.0.32 oder neuer |
| 6.0.0 bis 6.0.26 | 6.0.27 oder neuer |
| 7.0.0 bis 7.0.26 | 7.0.28 oder neuer |
| 8.0.0 bis 8.0.16 | 8.0.17 oder neuer |
| 8.2.0 bis 8.2.2 | 8.2.3 oder neuer |
Die Versionsstände 3.6, 4.0 und 4.2 sind außerhalb des Supports. Dort gibt es keinen Patch, nur den Umstieg.
MongoDB verarbeitet komprimierte Netzwerknachrichten, bevor eine Authentifizierung stattfindet. In der zlib-Dekompression prüfte der Server Längenangaben aus dem Nachrichtenkopf nicht ausreichend gegen die tatsächliche Nutzlast. Wer eine gezielt präparierte Nachricht schickt, bekommt nicht initialisierten Heap-Speicher zurückgeliefert. Also das, was zufällig gerade an dieser Stelle im Arbeitsspeicher lag.
Der Proof of Concept zeigt, was dabei herausfallen kann: interne MongoDB-Logs und Serverzustand, Konfiguration der WiredTiger-Storage-Engine, Systemdaten aus /proc, Container-Pfade sowie Verbindungs-UUIDs und Client-IPs. Der eigentliche Schaden entsteht über das, was Anwendungen in denselben Speicherbereichen hinterlassen: Connection-Strings, Passwörter, Tokens.
Drei Punkte, bei denen wir von der allgemeinen Berichterstattung abweichen.
Zur Bewertung. Im Umlauf sind zwei Zahlen: MongoDB stuft nach CVSS 4.0 mit 8.7 ein, NVD und Tenable nach CVSSv3 mit 7.5. Wir arbeiten mit der höheren Zahl. Nicht wegen der Zahl, sondern weil die Vorbedingungen in der Praxis fast immer erfüllt sind, sobald die Instanz überhaupt erreichbar ist: unauthentifiziert, aus der Ferne, ohne Nutzerinteraktion.
Zur Entwarnung. Frühe Meldungen sprachen von Remote Code Execution. Das war falsch, es ist ein reiner Lesezugriff. Mehrere Quellen haben daraufhin abgewiegelt. Das greift zu kurz: ausgelesene Zugangsdaten sind der Einstieg, nicht das Ende. Ein erfolgreicher Angriff sieht hier nicht nach Angriff aus, sondern nach einem gültigen Login zwei Wochen später.
Zur Lage im deutschen Mittelstand. Direkt aus dem Internet erreichbare MongoDB-Instanzen sehen wir hier selten. Häufig sehen wir dagegen flache interne Netze, in denen die Datenbank von jedem Client aus erreichbar ist. In dieser Konstellation ist MongoBleed keine Erstzugriffs-, sondern eine Eskalationsschwachstelle. Sie wird interessant, nachdem ein Angreifer bereits irgendwo im Netz steht. Das macht sie in der Bewertung nicht harmloser, sondern nur unauffälliger.
Der teure Teil dieser Schwachstelle ist nicht das Patchen. Der teure Teil ist die Entscheidung, welche Secrets rotiert werden müssen. Diese Frage beantwortet kein Schwachstellenscanner.
zlib aus net.compression.compressors entfernen und mongod neu starten. Das ist der von MongoDB benannte Workaround und schließt den Angriffsweg vollständig.Ehrlich vorweg: ein reiner Speicherlesezugriff hinterlässt auf dem Endpunkt keine klassischen Artefakte. Es gibt keine Datei, keinen Prozess, keinen Hash. Erkennung setzt deshalb an drei anderen Stellen an.
Zuerst die Frage, wo überhaupt MongoDB läuft. Über NG-SIEM lässt sich das über die Prozessdaten beantworten:
#event_simpleName = ProcessRollup2
| ImageFileName = /mongod(\.exe)?$/i
| groupBy([ComputerName, FileName, CommandLine], limit=max)Die Kommandozeile verrät dabei häufig direkt, ob über --networkMessageCompressors gesetzt wurde oder eine Konfigurationsdatei greift.
Spotlight führt CVE-2025-14847 als eigenen Eintrag. Der Filter liefert die betroffenen Hosts inklusive Versionsstand, ohne eigenen Scan:
cve.id:'CVE-2025-14847'Weil der Zugriff selbst unsichtbar bleibt, richtet sich die Erkennung auf die Verwendung der erbeuteten Zugangsdaten. Konkret: Anmeldungen von Datenbank- oder Servicekonten aus ungewohnten Quellen, außerhalb der üblichen Zeiten oder von Systemen, die diese Konten sonst nie nutzen. Bei angebundener Identitätsüberwachung ist genau das der Punkt, an dem eine MongoBleed-Ausnutzung sichtbar wird.
Alles, was auf dieser Seite steht, ist Ergebnis eigener Arbeit und frei nutzbar. Wir halten nichts zurück.
Sie können das eins zu eins selbst umsetzen. Wenn dafür die Zeit oder die Plattformtiefe fehlt, übernehmen wir es.
Die forensische Antwort auf die Frage, ob Zugangsdaten abgeflossen sind. Wir prüfen, ob API-Keys, Passwörter oder Session-Tokens aus dem Speicher abgeflossen sind, untersuchen die Logs auf Spuren einer Ausnutzung, analysieren den Netzwerkverkehr auf Hinweise auf Exfiltration und geben eine fachliche Einschätzung zur DSGVO-Meldepflicht. Ablauf: Kick-off, Sensor-Ausbringung, Auswertung durch unser Forensik-Team, gemeinsame Vorstellung des Berichts. Den zeitlichen Rahmen legen wir im Kick-off verbindlich fest, sobald Umgebungsgröße und Befundlage bekannt sind.
Bei konkretem Verdacht auf eine bereits erfolgte Kompromittierung erreichen Sie unsere Incident-Response-Bereitschaft rund um die Uhr unter +49 89 2000 7683. Auch ohne bestehenden Vertrag.
Sie setzen CrowdStrike Falcon ein, aber nicht mit uns? Wir gleichen Ihren Bestand gegen CVE-2025-14847 ab und liefern eine belastbare Betroffenheitsliste, bevor Sie ins Patchen gehen.
Nein. MongoDB hat Atlas-Instanzen automatisch aktualisiert. Es besteht kein Handlungsbedarf auf Kundenseite.
Der Patch schließt die Lücke für die Zukunft. Er beantwortet nicht, ob vorher bereits Speicherinhalte ausgelesen wurden. War die Instanz über längere Zeit ungepatcht und erreichbar, sollten Sie die dort verwendeten Zugangsdaten rotieren und eine forensische Prüfung erwägen.
Nein. Früh kursierende Meldungen dazu waren falsch. Es handelt sich um einen unauthentifizierten Lesezugriff auf Arbeitsspeicher. Das Risiko liegt in den ausgelesenen Zugangsdaten, die einen späteren, regulär aussehenden Zugriff ermöglichen.
Über db.adminCommand({ getCmdLineOpts: 1 }) in der mongosh oder direkt in /etc/mongod.conf unter net.compression.compressors. Steht dort kein zlib, ist der verwundbare Codepfad nicht erreichbar.
In Replica-Set-Konfigurationen ist ein rollierendes Update ohne Ausfall der Regelfall. Bei Einzelinstanzen ist ein kurzer Neustart nötig. Der Workaround (zlib deaktivieren) erfordert ebenfalls einen Neustart von mongod.
Nein. Die Analyse erfolgt so, dass Ihre Produktivumgebung nicht beeinträchtigt wird. Alle Maßnahmen stimmen wir vorab mit Ihnen ab.
