Was ist bei Mongoose passiert?

Die GitHub Advisory Database veröffentlichte am 10. November 2026 die Meldung GHSA-pcrw-h46h-c93h zu Mongoose. Sie beschreibt, dass sanitizeFilter in älteren Versionen nicht auf Abfragen mit countDocuments angewendet wurde. Diese Schutzfunktion soll Query Selector Injection verhindern. Wenn eine Anwendung nicht vertrauenswürdige Filter übernimmt, kann die Lücke daher eine NoSQL Injection ermöglichen.

Betroffen sind Versionen vor 6.13.11 sowie die Reihen 7.0.0 bis 7.8.11, 8.0.0 bis 8.24.2 und 9.0.0 bis 9.9.1. Behoben ist das Problem in 6.13.11, 7.8.12, 8.24.3 und 9.9.2. Das Advisory ordnet die Schwachstelle als kritisch ein, nennt CVE-2026-125120 und bewertet sie mit CVSS 9,8.

Die offiziellen Mongoose Releases vom 10. August 2026 nennen für alle vier gepflegten Hauptzweige denselben Fix: sanitizeFilter wird nun auch bei countDocuments und Cursor Abfragen angewendet. Dass die Sicherheitsmeldung später veröffentlicht wurde als die Releases, ändert nichts am praktischen Schritt. Betreiber sollten den tatsächlich eingesetzten Hauptzweig auf mindestens die genannte Patchversion aktualisieren.

Primärquelle: GitHub Advisory GHSA-pcrw-h46h-c93h vom 10. November 2026.

Die Änderung ist auch in den offiziellen Mongoose Releases dokumentiert.

Vier gepatchte Mongoose Hauptzweige und die Bewertung CVSS 9,8
Das Advisory nennt für die Hauptzweige 6 bis 9 jeweils eine gepatchte Version und bewertet die Schwachstelle mit CVSS 9,8.

Wer ist betroffen?

Prüfen sollten Betreiber von Node.js Anwendungen, die Mongoose in einem betroffenen Versionsbereich einsetzen. Besonders relevant sind Endpunkte, Suchfunktionen und Auswertungen, die countDocuments verwenden und Filterwerte aus Anfragen oder anderen nicht vollständig kontrollierten Quellen übernehmen.

Eine installierte betroffene Version beweist noch keine ausnutzbare Anwendung. Umgekehrt reicht eine globale sanitizeFilter Einstellung allein laut Advisory nicht als Entwarnung, weil genau deren fehlende Anwendung bei countDocuments das Problem war. Für die Priorisierung zählen deshalb Versionsstand, Verwendung von countDocuments und die Herkunft der Filter gemeinsam.

Ähnliche Prüfprinzipien beschreibt unser Beitrag zur kritischen JavaScript Injection in Handlebars.

Diagramm vom HTTP Aufruf über Eingabeprüfung und countDocuments bis MongoDB
Sichere Abfragen brauchen Eingabeprüfung und den wirksamen Mongoose Schutz direkt vor der Datenbank.

So prüfen Sie Mongoose in zwei Minuten

Führen Sie den Versionscheck im Verzeichnis der Anwendung aus. npm ls zeigt die tatsächlich aufgelöste Version im aktuellen Installationsbaum. In Monorepos und bei mehrfachen Abhängigkeiten hilft npm why zusätzlich dabei, den Ursprung des Pakets zu finden.

Suchen Sie anschließend im Anwendungscode nach countDocuments. Prüfen Sie bei Treffern, ob Filter aus URL Parametern, Request Bodies oder frei zusammengesetzten Objekten stammen. Diese kurze Sichtung ersetzt keinen Code Audit, trennt aber reine Paketfunde von Pfaden, die zeitnah untersucht werden sollten.

Versionsstand und Verwendung prüfen
npm ls mongoose --all
npm why mongoose
grep -R "countDocuments" src app lib 2>/dev/null
Terminal mit dem Befehl npm ls mongoose und der Ausgabe mongoose 8.24.3
Der reproduzierbare Test zeigt die gepatchte Version 8.24.3 in einer isolierten Beispielanwendung.

Was ist jetzt zu tun?

Aktualisieren Sie bevorzugt innerhalb des bereits eingesetzten Hauptzweigs. Das reduziert den Umfang gegenüber einem gleichzeitigen Sprung auf eine neue Hauptversion. Erstellen Sie vorher einen Arbeitszweig und sichern Sie die relevanten Daten. Ändern Sie Paketdatei und Lockdatei gemeinsam, installieren Sie sauber neu und prüfen Sie besonders Endpunkte mit Zählungen, Suche, Filtern und Berechtigungen.

Für Mongoose 8 bedeutet das mindestens 8.24.3, für Mongoose 9 mindestens 9.9.2. Nach dem Update sollten automatisierte Tests, ein kurzer Funktionstest gegen eine Testdatenbank und die Kontrolle des finalen Installationsbaums folgen. Erst danach gehört die Änderung in die Produktion. Beobachten Sie anschließend Fehlerquote, Antwortzeiten und Datenbankmeldungen.

  • Betroffenen Versionsstand und Verwendung von countDocuments erfassen.
  • Passende Patchversion im vorhandenen Hauptzweig eintragen.
  • Lockdatei aktualisieren und Abhängigkeiten sauber installieren.
  • Filter, Zählungen, Suche und Berechtigungen in einer Testumgebung prüfen.
  • Geprüften Stand ausrollen und Monitoring beobachten.

Weitere Beispiele für kontrollierte Node.js Updates finden Sie in unserem Beitrag zu React Server Components.

Der passende zweite Beitrag behandelt die kritische SVG Bildoptimierung in Next.js.

Übergangsmaßnahmen bis zum Update

Wenn ein sofortiger Rollout organisatorisch nicht möglich ist, nennt das Advisory eine Middleware, die mongoose.sanitizeFilter vor countDocuments ausdrücklich auf den Filter anwendet. Diese Maßnahme sollte wie Code behandelt, getestet und nach dem regulären Update wieder überprüft werden. Sie ersetzt das Update nicht.

Begrenzen Sie zusätzlich erlaubte Filterfelder und Operatoren an der Eingabegrenze, statt komplette Request Objekte an Mongoose weiterzugeben. Prüfen Sie Protokolle auf ungewöhnliche Fehler oder auffällige Abfragen, ohne sensible Inhalte dauerhaft zu speichern. Ein kurzfristig nicht benötigter Endpunkt kann bis zur Prüfung deaktiviert oder stärker geschützt werden.

Praxisbeleg und Einordnung aus dem Betrieb

Für diesen Beitrag haben wir am 11. November 2026 in einer isolierten Node.js Beispielanwendung Mongoose 8.24.3 installiert und den aufgelösten Stand mit npm ls mongoose kontrolliert. Das Ergebnis bestätigt nur die Versionsprüfung. Es beweist weder die Sicherheit einer konkreten Anwendung noch ersetzt es Tests ihrer Datenflüsse.

Autor ist die Devvibe Redaktion. Die technische Prüfung erfolgte automatisiert in der beschriebenen Testumgebung. Die redaktionelle Freigabe durch Matthias steht vor einer Veröffentlichung noch aus.

Fazit: Patchen, Pfade prüfen, ruhig bleiben

Die Meldung ist ernst, aber der Handlungsweg ist klar. Ermitteln Sie zuerst die installierte Version und die Verwendung von countDocuments. Aktualisieren Sie dann innerhalb des vorhandenen Hauptzweigs auf den gepatchten Stand und testen Sie die betroffenen Abfragen. Erst der konkrete Anwendungspfad zeigt, wie hoch das Risiko für Ihr System tatsächlich ist.

Wenn Zuständigkeit, Testumgebung oder Monitoring fehlen, lohnt sich ein wiederholbarer Wartungsprozess für Node.js Anwendungen. Er verbindet Abhängigkeitsupdates mit Funktionsprüfungen, dokumentierten Freigaben und einer kontrollierten Auslieferung.

Für neue und bestehende Webanwendungen beschreibt unsere Leistung Software MVP Entwicklung den technischen Rahmen.

Weitere aktuelle Hinweise finden Sie im Devvibe Magazin.