MongoDB-Sicherheitshinweis

 (mongodb.com)
2 Punkte von GN⁺ 2023-12-18 | 1 Kommentare | Auf WhatsApp teilen
  • MongoDB Alerts ist ein Hinweis-Hub, der Probleme bei Datenintegrität, Betrieb und CVE-Sicherheitsfragen an einer Stelle bündelt, damit sich versionsbezogene Auswirkungen und betroffene MongoDB-Deployments mit Handlungsbedarf prüfen lassen
  • Die Einträge zur Datenintegrität für 2026 umfassen Fehler bei absteigenden Bereichsabfragen auf _id in clustered collections, zugelassene Duplikate in unique indexes bei sharded clusters, Auslassungen im Relational Migrator sowie nicht angewandte read/write concerns bei direkter Verbindung zu einem shard
  • Auf betrieblicher Seite stellen wichtige öffentliche CAs bis April 2026 die Ausstellung von TLS-Zertifikaten mit clientAuth-EKU ein, wodurch mTLS- und X.509-Authentifizierungskonfigurationen in selbstverwalteten MongoDB-Deployments betroffen sein können
  • Der Sicherheitsabschnitt stellt für die Jahre 2019 bis 2026 CVE-Listen nach Produkt bereit, darunter MongoDB Server, Compass, mongosh, Treiber und Ops Manager
  • Praktiker sollten die verwendeten Versionen von Server, Atlas, Relational Migrator, Compass, mongosh und sprachspezifischen Treibern mit den betroffenen Bereichen abgleichen und auf Patch-Versionen aktualisieren oder die angekündigten Workarounds anwenden

Welche Bereiche die Seite „MongoDB Alerts“ abdeckt

  • MongoDB Alerts ist eine Seite, die wichtige Warnungen und Empfehlungen zu MongoDB bündelt
  • Eine umfassende Liste von Bugs und Feature Requests ist in MongoDB JIRA verfügbar
  • Neue Hinweise werden auch über den RSS Feed bereitgestellt
  • Die Seite ist in die folgenden Kategorien gegliedert
    • Data Integrity Related
    • Operations Related
    • Security Related: Common Vulnerabilities and Exposures (CVEs)
    • General

Warnungen zur Datenintegrität im Jahr 2026

  • Absteigende Bereichsabfragen auf _id in clustered collections

    • Hinweis vom 17. Juni 2026
    • Wenn in einer clustered collection auf das Feld _id eine absteigende Sortierung angewendet wird und Bereichsbedingungen der Form {$lt: A}, {$gt: A}, {$gte: A, $lt: B}, {$gt: A, $lte: B} verwendet werden, können Grenzdokumente fälschlich einbezogen oder ausgeschlossen werden
    • Nicht betroffen sind time series collections, non-clustered collections, clustered collections ohne absteigende Sortierung auf _id sowie Kombinationen von Vergleichsoperatoren mit demselben Ein-/Ausschlusstyp
    • Betroffene Versionen:
      • MongoDB 8.0.0–8.0.23
      • 8.2.0–8.2.9
      • 8.3.0–8.3.2
    • SERVER-121822

  • Duplikatgarantie bei unique indexes in sharded clusters

    • Hinweis vom 14. Mai 2026
    • Wenn in einem sharded cluster der shard key dem index key pattern entspricht oder ein strict prefix davon ist und ein unique index eine non-simple collation verwendet, wird Eindeutigkeit zwischen shards möglicherweise nicht erzwungen
    • Werte wie "YES" und "yes", die sich auf Byte-Ebene unterscheiden, unter der collation aber als gleich gelten, können unabhängig auf verschiedenen shards eingefügt werden
    • Die Problemvoraussetzungen sind mindestens zwei shards, ein unique index mit non-simple collation und ein shard key, der dem index key pattern entspricht oder ein strict prefix davon ist
    • Betroffene Versionen:
      • 5.0.0–5.0.32
      • 6.0.0–6.0.28
      • 7.0.0–7.0.31
      • 8.0.0–8.0.20
      • 8.2.0–8.2.6
    • SERVER-85346

  • Auslassungen bei Migrationen mit Relational Migrator

    • Hinweis vom 14. Mai 2026
    • Nutzer, die mit Relational Migrator migriert haben, können bei sharded cluster migration fehlende Dokumente erleben, wenn embedded documents oder embedded arrays vorhanden sind
    • Zyklische Mappings mit ausgeschlossenen foreign keys unter embedded arrays, source table columns, die in mehreren composite foreign key-Beziehungen verwendet werden, sowie die Auswahl kollidierender field names können Auslassungen, Inkonsistenzen oder falsch benannte Felder verursachen
    • Betroffen ist MongoDB Relational Migrator vor 1.16.0
    • SERVER-126522

  • Nicht angewandte read/write concerns bei direkter Verbindung zu einem shard

    • Hinweis vom 14. Mai 2026
    • Wird eine Verbindung direkt zu einem shard node statt über mongos hergestellt, wird die clusterweite Standard-read/write concern möglicherweise nicht angewendet
    • In diesem Fall können Writes statt mit der konfigurierten concern mit {w: 1} ausgeführt werden, und bei einem Rollback können bestätigte Writes verloren gehen
    • Verbindungen zu einem sharded cluster sollten nur über mongos erfolgen
    • Wenn eine direkte shard-Verbindung erforderlich ist, sollte sofort auf eine Patch-Version aktualisiert oder in der connection string eine explizite read/write concern wie {w: "majority"} angegeben werden
    • Betroffene Versionen:
      • 5.0.0–5.0.32
      • 6.0.0–6.0.28
      • 7.0.0–7.0.31
      • 8.0.0–8.0.19
      • 8.2.0–8.2.3
    • SERVER-111031

Wiederkehrende Muster in aktuellen Warnungen zur Datenintegrität

  • Sharding und Migration

    • Ein Eintrag vom März 2026 behandelt das Risiko von Datenverlust während chunk migrations in sharded collections mit compound wildcard indexes, die ein shard key prefix enthalten
    • Im November 2025 wurde ein Problem erfasst, bei dem cross-shard transactions unter bestimmten Failover-Bedingungen teilweise committet werden können
    • Im April 2024 wurde ein Problem aufgenommen, bei dem sharded multi-document transactions falsche Daten zurückgeben oder Writes auslassen können

  • Time series collections

    • Ein Eintrag vom November 2025 weist darauf hin, dass 2dsphere index keys für metric data in time series collections nicht erzeugt oder eingefügt werden, wodurch geospatial queries unvollständige Ergebnisse liefern können
    • Ein Eintrag vom August 2025 behandelt ein Problem, bei dem bestimmte Eingabemuster für double-precision metrics Datenkorruption verursachen können
    • Ein Eintrag vom Januar 2025 umfasst die Möglichkeit von Datenverlust in time series collections bei der Kombination aus gleichzeitigen Inserts mit ordered: false und retryable writes

  • Genauigkeit von Abfrageergebnissen

    • Im März 2026 wurde ein Problem erfasst, bei dem aggregation queries mit $group direkt nach $sort und den Accumulatoren $top oder $bottom falsche Ergebnisse zurückgeben können
    • Im Februar 2026 konnte das SQL interface falsche Ergebnisse zurückgeben, wenn in einer WHERE-Klausel eine OR-Bedingung UNKNOWN und die andere TRUE war
    • Im Juni 2025 wurde ein Problem gemeldet, bei dem Queries mit $elemMatch und string predicate einen Index mit unpassender collation verwenden und dadurch eigentlich einzuschließende Dokumente auslassen können

Betriebsbezogene Warnungen

  • Richtlinienänderung öffentlicher CAs zu clientAuth EKU

    • Hinweis vom 22. Januar 2026
    • Wichtige öffentliche Certificate Authorities setzen eine Richtlinienanforderung um, nach der bis April 2026 keine TLS-Zertifikate mehr ausgestellt werden, die die Extended Key Usage für client authentication (clientAuth) enthalten
    • Diese Änderung betrifft nur selbstverwaltete MongoDB-Deployments, die öffentliche CA-Zertifikate für mutual TLS (mTLS) oder X.509-Authentifizierung verwenden
    • Kunden mit selbstverwalteten Umgebungen müssen vor den Fristen im April/Mai 2026 auf eine private PKI infrastructure migrieren oder ihre MongoDB-Konfiguration ändern
    • Atlas-Kunden sind nicht betroffen
    • Betroffene Bereiche:
      • X.509 Cluster Authentication
      • X.509 Client Authentication
      • mTLS mit öffentlichen CA-Zertifikaten von Google Trust Services, Let’s Encrypt, DigiCert und Sectigo
    • Zugehöriger Hinweis

  • mongosh und Node.js REPL autocomplete

    • Hinweis vom 30. September 2025
    • Third-party distributions wie MongoDB Shell, installiert über Homebrew oder den npm package manager, können von einem Bug in der Node.js REPL betroffen sein
    • Während autocomplete können unbeabsichtigte side effects auftreten
    • Betroffen ist mongosh vor 2.5.8 in Verbindung mit Node.js 20.19.5–24.7.0
    • MONGOSH-2635

  • FIPS mode und OpenSSL 3

    • Hinweis vom 11. September 2025
    • MongoDB im FIPS mode, das unter Linux OpenSSL 3 für cryptographic operations verwendet, kann cryptographic algorithms aus dem non-FIPS provider nutzen
    • Dadurch kann sich ein Client mit einem non-FIPS-compliant cryptographic algorithm per TLS mit MongoDB im FIPS mode verbinden
    • Betroffene Versionen:
      • 6.0.0–6.0.25
      • 7.0.0–7.0.22
      • 8.0.0–8.0.12
    • SERVER-109268

CVE-Sicherheitshinweise 2026

  • Schwachstellen in MongoDB Server

    • CVE-2026-11933 vom 12. Juni 2026 ist eine post-authentication use-after-free-Schwachstelle bei der serverseitigen BSON-to-array conversion in JavaScript und hat einen Score von 8.8
    • Betroffene Versionen sind 8.3.3 und früher, 8.2.10 und früher, 8.0.25 und früher, 7.0.36 und früher, 6.0.28 und früher, 5.0.33 und früher sowie 4.4.30 und früher
    • SERVER-128125

  • Pre-authentication denial of service

    • CVE-2026-9740 kann durch unbounded recursion in BSONColumn interleaved-reference vor der Authentifizierung einen Stack Overflow auslösen und hat einen Score von 8.7
    • Betroffene Versionen sind vor 8.3.3, vor 8.2.10, vor 8.0.24 und vor 7.0.35
    • SERVER-125063
    • CVE-2026-25611 ist eine pre-authentication memory exhaustion denial of service, bei der eine unauthenticated message den Speicher erschöpfen kann; der Score liegt bei 8.7
    • Betroffene Versionen sind vor 8.2.4, vor 8.0.18 und vor 7.0.29
    • SERVER-116210

  • Sensible Informationen in Logs

    • CVE-2026-9735 beschreibt ein Problem, bei dem MongoDB Server Authentifizierungsparameter und Zugangsdaten in das server log schreiben kann; betroffen ist MongoDB Server vor 8.3.3
    • SERVER-126506
    • CVE-2026-9751 beschreibt ein Problem, bei dem der Parameter ldapQueryPassword in mongod.log geschrieben werden kann, wenn er per Runtime-Command setParameter gesetzt wird
    • Betroffene Versionen sind vor 8.3.3, vor 8.2.10, vor 8.0.24 und vor 7.0.35
    • SERVER-123370

  • Server-Abstürze und Verfügbarkeitsprobleme

    • CVE-2026-9754 beschreibt ein Problem, bei dem ein authentifizierter Benutzer mit read role im filemd5-Command Teile nicht initialisierten Stack-Speichers lesen kann; der Score beträgt 7.1
    • CVE-2026-9753 kann einen Server-Absturz verursachen, wenn ein malformed binary diff an $_internalApplyOplogUpdate übergeben wird
    • CVE-2026-9752 kann einen Server-Absturz bei der Erzeugung von 2dsphere index keys verursachen, wenn eine GeometryCollection mit strict-winding polygon vorhanden ist
    • CVE-2026-9749 kann bei Verwendung von MaxKey() einen Server-Absturz auslösen

  • Treiber und Tools

    • CVE-2026-9101 ist eine prototype pollution beim CSV parsing in Compass; betroffen sind Compass 1.36.3 bis 1.49.5
    • CVE-2026-9100 betrifft einen heap memory out-of-bounds read und Abstürze im legacy GridFS file reader des C Driver
    • CVE-2026-6811 kann durch stack exhaustion im MongoDB PHP driver einen Application-Absturz auslösen
    • CVE-2026-2303 ermöglicht durch einen heap out-of-bounds read im GSSAPI C wrapper des MongoDB Go Driver einen Application-Absturz oder Informationsleck
    • CVE-2026-2302 betrifft unsafe reflection in Mongoid::Criteria.from_hash des MongoDB Ruby Driver

  • Ops Manager RCE

    • CVE-2026-8431 ist eine RCE über den webhook body in Ops Manager und hat einen Score von 9.4
    • Wenn ein administrativer Benutzer einen webhook konfigurieren kann, lassen sich über bestimmte Werte in der Payload beliebige Befehle ausführen
    • Betroffen ist Ops Manager 7.0 bis vor 8.0.23
    • Ops Manager release notes

Produktgruppen, die seit 2025 häufig in Sicherheitshinweisen auftauchen

  • MongoDB Server

    • Wiederholt wurden CVEs zu Server-Abstürzen, denial of service, privilege escalation, certificate validation, malformed BSON, aggregation, query planner, sharding und time series registriert
    • Die betroffenen Versionen unterscheiden sich je nach Hinweis und betreffen die Reihen 5.0, 6.0, 7.0, 8.0, 8.1, 8.2 und 8.3

  • Clients und Treiber

    • Als betroffene Produkte erscheinen C Driver, PHP Driver, Go Driver, Ruby Driver, Rust Driver, Node.js Driver, Java driver, .NET/C# Driver, PyMongo, libbson und js-bson
    • Einige Einträge behandeln Probleme, bei denen authentication-related data über command listener oder connection pool event listener offengelegt werden

  • Betriebstools

    • Compass, mongosh, MongoDB for VS Code, Atlas Kubernetes Operator, Enterprise Kubernetes Operator, Ops Manager, Cloud Manager, BI Connector, Atlas SQL ODBC driver und Database Tools gehören zu den betroffenen Produkten
    • Dazu zählen fehlende ACL-Konfigurationen im Windows-Installations-MSI, local privilege escalation, control character injection und unzureichende Eingabevalidierung im Zusammenhang mit MITM

Allgemeine Sicherheitshinweise

  • Der Abschnitt General enthält Updates zu einem Sicherheitsvorfall, der erstmals am 16. Dezember 2023 öffentlich gemacht wurde
  • Die Einträge vom 28. und 29. Dezember 2023 erklären, dass keine Hinweise auf unbefugten Zugriff auf MongoDB-Atlas-Cluster oder auf in Atlas-Clustern gespeicherte Kundendaten gefunden wurden
  • Der Eintrag vom 26. Dezember 2023 weist auf Kundenprobleme beim Login aufgrund stark ansteigender Login-Versuche hin
  • Der Eintrag vom 24. Januar 2024 verweist auf die Veröffentlichung der Post Event Summary von MongoDB
  • MongoDB Security Incident Post Event Summary

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-12-18
Meinungen auf Hacker News

  • Ich bin derzeit komplett aus dem Atlas-Konto und dem Support-Portal ausgesperrt.
    Wir verwenden Mongo- und Okta-Authentifizierung, aber jeder Login-Versuch scheitert auf der Anmeldeseite mit „The request contained invalid data.“
    Das Problem ist, dass auch das Support-Portal Authentifizierung verlangt – man muss sich also authentifizieren, um Hilfe bei einem Authentifizierungsfehler zu bekommen.
    Mich würde interessieren, ob andere ebenfalls Probleme beim Zugriff auf das Dashboard haben.
    Nachtrag: Gegen 17:15 Uhr US-Ostküstenzeit funktionierte die Authentifizierung wieder, und der Zugriff auf das Dashboard war ebenfalls wieder möglich.

    • Als MongoDB-Mitarbeiter kann ich sagen: Die Login-Probleme stehen nicht im Zusammenhang mit dem Sicherheitsvorfall.
      Da alle Kunden und Nutzer gleichzeitig benachrichtigt wurden, ist die Zahl der Login-Versuche stark angestiegen.
      Falls es weiterhin Login-Probleme gibt, bitte in ein paar Minuten erneut versuchen.
      Bitte die Hinweis-Seite weiter im Blick behalten: https://www.mongodb.com/alerts
    • Beim Einloggen bekomme ich einen upstream request timeout.
    • Erlebe dasselbe mit Google SSO.

  • Mir gefällt, dass die Mitteilung knapp und auf den Punkt ist.
    Sie sagt klar, dass es noch eine frühe Phase ist, welchen Umfang man derzeit kennt und dass weitere Updates folgen, sobald Informationen eintreffen.
    Ich hoffe, man reagiert nicht so, als müsse MongoDB dafür bestraft werden, dass sie nicht mehr Informationen hineingepackt haben, obwohl die Untersuchung offensichtlich noch ganz am Anfang steht.

    • Es heißt, es sei erst am 13. entdeckt worden und man gehe davon aus, dass es schon eine Weile lief.
      Ob Nutzerdaten betroffen waren, ist im Grunde nicht einmal sicher; es wirkt, als hätten sie das noch nicht offengelegt oder würden nur „nein“ sagen. Darauf braucht es Antworten.
    • Zustimmung.
      MongoDB bekommt zwar diverse Kritik ab, aber diese Reaktion verdient in puncto Ehrlichkeit, Transparenz und Vertrauen durchaus Anerkennung.
      Ich wünschte, andere Unternehmen würden so vorgehen; und weil MongoDB diese Prinzipien hier direkt zeigt, bin ich eher bereit, mit ihnen Geschäfte zu machen.

  • Dort steht regularly rotate their MongoDB Atlas passwords – habe ich da Kontext übersehen?
    Oder empfiehlt ein modernes Security-Team wirklich regelmäßige Passwortwechsel?

    • Secrets für Anwendungen regelmäßig zu rotieren ist gut.
      Nutzer zu zwingen, ihre Passwörter regelmäßig zu ändern, ist eher nicht gut.

  • Wenn man betroffen ist, weiß ich nicht, wie man seine Systeme auf auffälliges Verhalten überwachen sollte.
    Nur in die Logs zu schauen, wirkt nicht ausreichend.

  • Das zeigt die Risiken extremer Zentralisierung.
    Selbst wenn Atlas-Kunden nicht direkt betroffen waren, ist es natürlich, sich Sorgen zu machen, wenn nach der Mitteilung Website oder Support-Kanäle überlastet sind.
    Um in so einem Fall echte Redundanz zu schaffen, bräuchte es mehr unabhängige MongoDB-DBaaS-Anbieter, aber das wurde durch die Umstellung auf die SSPL-Lizenz stark eingeschränkt.
    Ich hoffe, FerretDB baut eine tragfähige Alternative auf.

    • „Extreme Zentralisierung“? Warte erst mal, bis us-East-1 ausfällt.

  • Die Sicherheitsmitteilung, die ich heute erhalten habe, besagte, dass MongoDB unbefugten Zugriff auf einige Unternehmenssysteme untersucht und dass Kundenkonto-Metadaten sowie Kontaktinformationen offengelegt wurden.
    Derzeit wisse man nicht, dass Daten offengelegt wurden, die Kunden in MongoDB Atlas gespeichert haben.
    Verdächtige Aktivitäten seien am Mittwochabend, dem 13. Dezember 2023, US-Ostküstenzeit, entdeckt worden; man habe sofort die Incident-Response-Prozesse gestartet und gehe davon aus, dass der Zugriff schon einige Zeit vor der Entdeckung andauerte.
    Kunden wurden aufgefordert, auf Social-Engineering- und Phishing-Angriffe zu achten; falls noch nicht geschehen, wurden phishing-resistente Multi-Faktor-Authentifizierung und Passwortrotation empfohlen. Weitere Informationen würden auf mongodb.com/alerts aktualisiert.

    • Ich habe dieselbe E-Mail bekommen.
      Zum Glück nutze ich MongoDB Atlas tatsächlich nicht.

  • „Ihre Daten sind sicher. Wir haben sie schließlich nie auf die Festplatte geschrieben.“

  • Ich habe MongoDB noch nie benutzt und frage mich, warum Leute MongoDB statt anderer Datenbanken wählen.

    • Es ist sehr flexibel.
      Man entwickelt nicht gegen ein Schema; wenn man etwa Features und Daten schnell ändern will, muss man sich viel weniger Gedanken über Migrationen machen.
      Für Startups, die schnell vorankommen wollen, ist das ein großer Vorteil.
      Queries sehen aus wie Anwendungscode, sodass man weniger Denkarbeit darauf verwenden muss, Ideen in SQL-Queries zu übersetzen; meiner Erfahrung nach führt das zu Queries, die weniger bruchanfällig sind.
      Auch um Injection-Angriffe muss man sich weniger kümmern, solange man nicht absichtlich gefährliche Strukturen baut, und ich finde, komplexere Queries lassen sich leichter schreiben als in SQL.
      Typumwandlungen kann man ebenfalls im Code erledigen statt mit plattformspezifischen Inline-SQL-Funktionen wie field_name::timestamp.
      Es gibt eine einheitliche Grundlage für Queries und Entwicklung, und man entwickelt kaum wie bei SQL je nach Dialekt.
      Für die meisten Use Cases skaliert es ziemlich gut und einfach, und weil es nur eine Art MongoDB gibt, gibt es auch weniger Raum für dogmatische Verwirrung über bestimmte Varianten.
    • Es war ein früher Akteur aus der Zeit, als alle dachten, NoSQL-Dokumentdatenbanken würden jedes Problem lösen.
    • MongoDB ist eine der typischen NoSQL-Optionen.
      Wenn man ein flexibles Schema gut findet, ist MongoDB hervorragend; wenn man flexible Schemas schlecht findet, eher nicht.
      Zusammengefasst ist das alles.
    • Ich nutze es on-premises, genauer gesagt auf einem VPS.
      JSON-Dokumente lassen sich leicht speichern und bearbeiten.
      Wenn die Daten baumartig aufgebaut sind, passt es auch für große Dokumente ziemlich gut.
      Wenn man auf Beziehungen zwischen Dokumenten angewiesen ist, ist eine SQL-Datenbank besser, aber in vielen Fällen – praktisch in fast allen gewöhnlichen Fällen – braucht man relationale SQL-Beziehungen nicht unbedingt.
      MongoDB kann Beziehungen ebenfalls handhaben, aber es ist etwas komplizierter.
    • Der Einstieg ist ziemlich einfach.
      Auch MQL ist leicht zu verstehen und sorgt dafür, dass sich MongoDB in gewissem Maß angenehm anfühlt.
      Zur Einordnung: Ich arbeite bei MongoDB.

  • Ich frage mich, warum Leute heutzutage weiterhin MongoDB statt Postgres wählen.
    Falls ich etwas übersehe, würde ich es wirklich gern wissen; ich habe auch nichts gegen JSON-Daten an sich und nutze häufig jsonb-Tabellen in Postgres.

    • Der Grund, MongoDB zu nutzen, ist, dass der Einstieg leicht ist.
      Es erledigt „Datenbankzeug“ und „Authentifizierung“.
      Ich habe aufgegeben, gegen diesen Trend anzukämpfen, und wenn ich sehe, dass Entwickler am Anfang MongoDB verwenden, werte ich das inzwischen sofort als Zeichen, dass sie noch Stützräder dran haben.