MongoBleed: Wenn Nachlässigkeit zur Sicherheitslücke wird

Deutschland auf Platz drei – aber nicht beim Patchen

Kurz vor Jahresende 2025 wurde bekannt, was längst Praxis war: Über 11.500 MongoDB-Instanzen in Deutschland sind über das Internet frei zugänglich und anfällig für eine kritische Sicherheitslücke, die unter dem Namen MongoBleed bekannt wurde. Weltweit liegt Deutschland damit auf einem traurigen dritten Platz – direkt hinter China und den USA. Besonders pikant: Kein Hoster weltweit zählt mehr verwundbare Instanzen als Hetzner, ein deutscher Anbieter.

Was auf den ersten Blick wie ein weiteres Kapitel in der endlosen Reihe von CVEs erscheinen mag, ist in Wahrheit ein strukturelles Problem: Es geht nicht um den Fehler im Code, sondern um organisatorisches Versagen im Betrieb digitaler Infrastrukturen – quer durch Anbieter, Kunden und Verantwortungsbereiche.

Worum geht es bei MongoBleed?

MongoBleed bezeichnet die Sicherheitslücke CVE-2025-14847 mit einem CVSS-Score von 8.7 (hoch). Sie betrifft MongoDB-Instanzen, bei denen zlib-Kompression aktiviert ist – ein Konfigurationsmerkmal, das laut Sicherheitsforschern häufig standardmäßig gesetzt ist.

Die Lücke erlaubt es Angreifern, ohne Authentifizierung über das Netzwerk auf sensible Daten wie Zugangsdaten oder Inhalte produktiver Datenbanken zuzugreifen. Der öffentliche Exploit-Code ist bereits verfügbar, die Zahl der potenziellen Angriffe steigt täglich.

Weltweit sind laut Shodan etwa 90.000 MongoDB-Instanzen betroffen. Deutschland liegt mit 11.547 verwundbaren Instanzen auf Platz drei – und unter den Providern sticht Hetzner mit über 6.800 exponierten Systemen hervor.

MongoDB: Flexibel, beliebt – aber kein Selbstläufer

MongoDB ist eine dokumentenorientierte NoSQL-Datenbank, die sich besonders gut für moderne Web- und Big-Data-Anwendungen eignet. Sie ist skalierbar, schemalos, schnell und bei Entwicklerteams beliebt für ihre Flexibilität im Umgang mit komplexen und unstrukturierten Daten.

Doch genau diese Flexibilität bringt auch Verantwortung mit sich. MongoDB ist kein Plug-and-Play-Produkt mit Sicherheitsgarantie, sondern verlangt nach einem bewussten und professionellen Betrieb – insbesondere, wenn die Instanzen öffentlich erreichbar sind oder produktive Daten enthalten.

Cloud ist kein Sicherheitsversprechen – sie ist ein Betriebsmodell

Besonders brisant: Die Mehrheit der verwundbaren Instanzen läuft bei bekannten IaaS-Providern wie Hetzner, Alibaba oder Google Cloud. Dabei zeigt sich erneut ein gefährlicher Irrglaube:

„Weil es in der Cloud läuft, ist es sicher."

Das Gegenteil ist der Fall. Die Verantwortung verschiebt sich lediglich – sie verschwindet nicht. Cloud-Anbieter stellen Ressourcen bereit, aber die Sicherheit der Anwendungen, Konfigurationen und Daten bleibt in der Verantwortung des Nutzers.

Dass Hetzner an der Spitze der verwundbaren Systeme steht, bedeutet nicht zwangsläufig Fehlverhalten des Anbieters – aber es zeigt, wie unzureichend die Transparenz, Kontrolle und Sicherheitspraxis in der Nutzung von IaaS-Infrastruktur noch immer ist. Die Cloud wird zum Sicherheitsrisiko, wenn Sicherheitsstandards nicht systematisch eingefordert und überprüft werden.

Das eigentliche Problem: Monatelange Untätigkeit

Die Schwachstelle ist nicht neu. Der Exploit ist öffentlich, die Patches stehen bereit, Gegenmaßnahmen sind bekannt. Und dennoch bleiben zehntausende Instanzen ungepatcht, unsicher und offen erreichbar. Das ist kein technisches, sondern ein organisatorisches Problem – ein Systemversagen im IT-Betrieb.

Wir sehen hier ein Muster, das sich seit Jahren wiederholt:

1. Eine kritische Lücke wird entdeckt.
2. Sicherheitsforscher veröffentlichen den Exploit.
3. Medien berichten, IT-Abteilungen reagieren langsam oder gar nicht.
4. Angreifer nutzen die Schwachstelle systematisch aus.

Das war bei CitrixBleed so, bei Log4Shell, bei Exchange – und jetzt bei MongoBleed.

Digitale Souveränität beginnt mit Verantwortung

Deutschland diskutiert über digitale Souveränität, Open-Source-Förderung und strategische Abhängigkeiten. Doch diese Diskussion bleibt akademisch, wenn gleichzeitig tausende produktive Datenbanken ungepatcht im Netz stehen – mit kritischen Schwachstellen, die über Wochen hinweg ignoriert werden.

Open Source ist nicht das Problem. Im Gegenteil: MongoDB hat zeitnah Patches geliefert – transparent, dokumentiert, nachvollziehbar. Das Risiko entsteht dort, wo Betrieb, Wartung und Sicherheit billig ausgelagert werden, ohne verbindliche Standards, ohne Monitoring, ohne Verantwortlichkeit.

Was jetzt zu tun ist – Empfehlungen für Betreiber

Ob Startup, Mittelstand oder Konzern – wer MongoDB oder andere produktive Dienste betreibt, sollte jetzt aktiv werden:

1. Sicherheitsstatus prüfen:
   • Ist zlib-Kompression aktiviert?
   • Ist die Instanz öffentlich zugänglich?
   • Läuft eine verwundbare Version?
2. Sofortige Maßnahmen ergreifen:
   • Patchen auf aktuelle Versionen
   • Falls kurzfristig nicht möglich: zlib deaktivieren, Port 27017 intern absichern (z. B. per VPN oder Firewall)
3. Verantwortlichkeiten klären:
   • Wer ist zuständig für Security-Monitoring?
   • Gibt es automatisierte Patch-Prozesse?
   • Werden offene Ports und Dienste regelmäßig geprüft?
4. Langfristige Lessons:
   • Sicherheits-Checks gehören zum Deployment-Standard.
   • Cloud-Nutzung braucht Sicherheitsrichtlinien, kein „Fire and Forget".
   • Sicherheitsupdates sind Betriebspflicht, kein „Nice to Have".

Fazit: Sicherheit ist eine Frage der Haltung

MongoBleed ist kein Einzelfall. Es ist ein Symptom für einen strukturellen Mangel an Sicherheitskultur im Betrieb digitaler Systeme. Nicht MongoDB ist unsicher – unsicher ist der Umgang damit.

In einer Zeit, in der Daten das Fundament wirtschaftlicher und staatlicher Prozesse sind, darf Security nicht mehr auf die letzte Meile im DevOps Prozess verschoben werden. Wer Systeme betreibt, trägt Verantwortung. Wer Cloud nutzt, braucht Kompetenz. Und wer kritische Infrastruktur hostet, darf sich nicht hinter dem Kunden verstecken.

Sicherheit ist keine Funktion der Software – sondern der Organisation dahinter.