Was ist NoSQL-Injection? Funktionsweise und Schutzmaßnahmen

Was ist NoSQL-Injection?

NoSQL-Injection ist eine Schwachstelle, über die Angreifer Abfragen an NoSQL-Datenbanken manipulieren können. Dazu schleusen sie schädliche Operatoren, JavaScript-Code oder präparierte Syntax über ungeprüfte Benutzereingaben ein. Sie ist in der Common Weakness Enumeration (CWE) als CWE-943, „Unzureichende Neutralisierung spezieller Elemente in der Datenabfragelogik“, klassifiziert. Betroffen sind Datenbanken wie MongoDB, Redis, Cassandra und Elasticsearch, die statt Standard-SQL flexible Abfragesprachen ohne festes Schema verwenden.

Ein erfolgreicher Angriff hat weitreichendere Folgen als eine einzelne manipulierte Abfrage. Angreifer können die Authentifizierung vollständig umgehen, sensible Daten Zeichen für Zeichen auslesen, Datensätze ändern, Denial of Service auslösen oder beliebigen Code auf dem Server ausführen. Wie der OWASP WSTG feststellt, „können die Auswirkungen gravierender sein als bei herkömmlicher SQL-Injection“. Denn NoSQL-Injection-Payloads können innerhalb einer prozeduralen Sprache wie JavaScript ausgeführt werden, nicht nur in einer deklarativen Abfragesprache.

NoSQL-Datenbanken bilden heute die Grundlage für Anmeldesysteme, Chat-Plattformen, E-Commerce-Kataloge und IoT-Verwaltungskonsolen. Ihre zunehmende Verbreitung und der verbreitete Irrglaube, „kein SQL bedeutet keine Injection“, machen diese Schwachstellenklasse zu einem anhaltenden Risiko. Der Irrglaube ist falsch. Angreifer verlassen sich darauf. 

Bevor wir uns die Funktionsweise von NoSQL-Injection in der Praxis ansehen, lohnt sich ein Blick auf ihre Einordnung in gängige Frameworks zur Klassifizierung von Schwachstellen.

OWASP-Klassifizierung

OWASP ordnet NoSQL-Injection sowohl 2021 als auch in den Top 10 von 2025 der Kategorie Injection zu. Sie gehört zur selben Risikofamilie wie SQL-Injection, hat aber eine andere Klassifizierung der Ursache. Das beeinflusst, wie Sie darauf testen und entsprechende Funde melden.

Der entscheidende Unterschied liegt in der CWE-Zuordnung. Herkömmliche SQL-Injection fällt unter CWE-89 (unzureichende Neutralisierung spezieller Elemente in einem SQL-Befehl). NoSQL-Injection wird dagegen CWE-943 (unzureichende Neutralisierung spezieller Elemente in der Datenabfragelogik) zugeordnet. CWE-943 umfasst Abfragesprachen jenseits von SQL, darunter die Binary JSON (BSON)-Operatoren von MongoDB, Redis-Protokollbefehle und REST-basierte Abfragen von CouchDB.

Wenn Ihr Sicherheitstestprogramm oder Ihre Compliance-Berichterstattung nur CWE-89 erfasst, können NoSQL-Injection-Funde falsch eingeordnet oder ganz übersehen werden. Richten Sie Ihre Tools und Taxonomie an CWE-943 aus, um diese blinde Stelle zu beseitigen. 

Nach der Einordnung folgt der nächste Schritt: die konkreten Mechanismen verstehen, mit denen Angreifer NoSQL-Abfrageschnittstellen ausnutzen.

Wie funktioniert NoSQL-Injection?

NoSQL-Injection nutzt die Lücke zwischen den erwarteten und den tatsächlichen Benutzereingaben Ihrer Anwendung aus. Während SQL-Injection auf eine universelle Abfragesprache abzielt, variiert NoSQL-Injection je nach Datenbank. MongoDB verwendet BSON/JSON-Abfrageoperatoren, Redis das Übertragungsprotokoll Redis Serialization Protocol (RESP) und CouchDB stellt eine HTTP-REST-API bereit. Jede Datenbank bietet eine andere Angriffsfläche, doch das Grundprinzip bleibt gleich: Vom Benutzer kontrollierte Daten gelangen ohne ausreichende Validierung in eine Abfrage und verändern deren Logik.

Operator-Injection: das häufigste Muster

In einer typischen Node.js-Anwendung mit MongoDB-Backend könnte ein Login-Endpoint eine Abfrage wie diese erstellen:

Eine legitime Anfrage sendet {"username":"admin","password":"secret"}. Ein Angreifer kann jedoch Folgendes übermitteln:

Der Operator $ne („ungleich“) weist MongoDB an, alle Benutzer zurückzugeben, deren Benutzername und Passwort nicht "invalid" entsprechen. Das trifft auf jedes gültige Konto zu. Die Authentifizierung wird mit einer einzigen Anfrage umgangen, ohne Brute-Force-Angriff.

JavaScript-Injection über $where

Wenn Anwendungen Benutzereingaben an den Operator $where von MongoDB oder an Funktionen wie mapReduce, $accumulator oder $function übergeben, führt die Datenbank sie als serverseitiges JavaScript aus. Ein Angreifer kann mit einer eingeschleusten Endlosschleife die MongoDB-Instanz blockieren und einen Denial-of-Service auslösen. Über den Zugriff auf Daten hinaus kann die Ausführung beliebigen JavaScripts zu einer Remote-Code-Ausführung auf dem Datenbankserver führen.

Blinde Datenextraktion

Wenn die Anwendung Abfrageergebnisse nicht direkt zurückgibt, extrahieren Angreifer Daten Zeichen für Zeichen mit booleschen oder zeitbasierten Verfahren. Dazu übermitteln sie Regex-Muster wie password[$regex]=^a und prüfen, ob sich die Antwort von der auf eine bekanntermaßen falsche Bedingung unterscheidet. So können sie Passwörter, Token und andere Geheimnisse rekonstruieren, ohne dass ein direktes Datenleck sichtbar wird.

Redis-Befehlsinjektion über CRLF

In RESP werden Befehle durch Wagenrücklauf- und Zeilenvorschub-Sequenzen (CRLF) getrennt (\r\n). Wenn eine Anwendung Benutzereingaben ohne Bereinigung in Redis-Befehle auf Protokollebene einfügt, kann ein Angreifer mit CRLF-Sequenzen den aktuellen Befehl beenden und über dieselbe Verbindung unautorisierte Befehle einschleusen.

Redis speichert Daten in Schlüssel-Wert-Paaren. Eingeschleuste Befehle wie SET, GET und CONFIG können sensible Daten auslesen, Schlüssel überschreiben oder den Server vollständig umkonfigurieren. Diese Technik wird häufig mit Server-Side Request Forgery (SSRF) kombiniert: Der Angreifer nutzt eine SSRF-Schwachstelle, um eine interne Redis-Instanz zu erreichen, die nicht über das öffentliche Internet zugänglich ist. Anschließend schleust er über den SSRF-Kanal zusätzliche Befehle ein.

HTTP-API-Injection in CouchDB

CouchDB stellt eine REST/HTTP-API bereit. Alle Datenbankoperationen erfolgen daher über standardmäßige HTTP-Anfragen mit JSON-Payloads. Eine Injection entsteht, wenn eine Anwendung unbereinigte Benutzereingaben an CouchDB-Abfrageparameter, View-Definitionen oder Mango-Selektorobjekte übergibt.

Da CouchDB in JavaScript geschriebene MapReduce-Views verwendet, besteht ein ähnliches Risiko der serverseitigen Codeausführung wie beim Operator $where von MongoDB. Kann ein Angreifer das in einer MapReduce-View ausgeführte JavaScript beeinflussen, kann er beliebigen Code auf dem Datenbankserver ausführen. Auch die Replikationsfunktion von CouchDB lässt sich mit präparierten HTTP-Anfragen missbrauchen, um SSRF gegen interne Dienste auszulösen.

Jede NoSQL-Datenbank bietet eine eigene Angriffsfläche: MongoDB mit seinen BSON-Operatoren, Redis mit CRLF-Injection auf Protokollebene und CouchDB mit seiner REST-basierten API. Ihre Abwehr gegen NoSQL-Injection muss auf die jeweilige Abfrageschnittstelle abgestimmt sein.

Diese Mechanismen funktionieren über verschiedene Inhaltstypen, Transportschichten und Frameworks hinweg. Die zugrunde liegenden Ursachen wiederholen sich. Genau das verschafft Sicherheitsteams einen Vorteil.

Ursachen von NoSQL-Injection

NoSQL-Injection entsteht nicht durch einen einzelnen Programmierfehler. Sie resultiert aus dem Zusammenspiel architektonischer Annahmen, des Verhaltens von Frameworks und fehlender Validierungsebenen zur Laufzeit.

Unzureichende Eingabevalidierung und fehlende Typprüfung

Ihre Anwendung geht möglicherweise davon aus, dass ein Feld wie password immer als Zeichenfolge ankommt. HTTP-Anfragekörper, JSON-Nutzdaten und URL-kodierte Parameter können jedoch Objekte und Arrays enthalten. Wenn Express.js body-parser password[$ne]=x empfängt, deserialisiert er den Wert automatisch zu { password: { $ne: "x" } }, einem MongoDB-Operatorobjekt. Das geschieht, bevor der Anwendungscode den Wert verarbeitet.

Dynamische Erstellung von Abfragen

Wenn Sie Abfragen durch Verkettung oder Interpolation von Zeichenfolgen statt mit strukturierten Abfrageobjekten erstellen, können Angreifer die Abfragesyntax aufbrechen und neue Logik einschleusen. Das MongoDB-Forum bestätigt: "In den meisten Fällen entstehen externe Injections durch die unsichere Verkettung von Zeichenfolgen beim Erstellen von Abfragen."

Serverseitiges JavaScript bleibt aktiviert

MongoDB unterstützt die Ausführung von JavaScript über $where, mapReduce, $accumulator und $function. Die MongoDB-Checkliste empfiehlt ausdrücklich, serverseitiges Scripting mit --noscripting zu deaktivieren, wenn diese Operationen nicht verwendet werden. Bleiben sie aktiviert, entsteht eine Angriffsfläche für die Ausführung beliebigen Codes.

Typumwandlung auf Framework-Ebene

PHP wandelt username[$ne]=toto automatisch in ['username' => ['$ne' => 'toto']] um. Express.js body-parser macht dasselbe mit URL-kodierten Formulardaten und deserialisiert password[$ne]=x zu { password: { $ne: "x" } }, einem MongoDB-Operatorobjekt, bevor die Anfrage den Anwendungscode erreicht. Dieses Verhalten von Frameworks verwandelt scheinbar harmlose HTTP-Parameter in Datenbankoperatoren, ohne dass Entwickler bewusst eingreifen.

Schwachstellen auf ORM-Ebene

Selbst wenn MongoDB gehärtet ist, kann die Object-Relational-Mapping-Bibliothek (ORM) Ihrer Anwendung Angriffsflächen für Injections schaffen. CVE-2024-53900 zeigte, dass der Operator $where von Mongoose über benutzergesteuerte Eingaben ausgenutzt werden konnte. CVE-2025-23061, eine unvollständige Behebung der ersten Schwachstelle, zeigte, dass $where weiterhin durch Verschachtelung unter $or in Mongoose populate().match-Funktion und umgehen damit den Schutz auf Serverebene vollständig.

Deaktivierte Wire-Protocol-Validierung

MongoDB validiert eingehende Dokumente auf Wire-Protocol-Ebene über die Einstellung net.wireObjectCheck. Wird sie deaktiviert, entfällt eine strukturelle Schutzschicht, die verhindert, dass fehlerhaftes BSON die Abfrage-Engine erreicht.

Diese Ursachen schaffen eine Angriffsfläche, die vom HTTP-Parsing bis zur Datenbankausführung reicht und unmittelbar Geschäftsrisiken birgt.

Auswirkungen und Risiken

NoSQL-Injection betrifft alle Dimensionen der CIA-Triade aus Vertraulichkeit, Integrität und Verfügbarkeit, oft gleichzeitig.

• Vertraulichkeit: Angreifer können beliebige Dokumente lesen, Feldnamen ermitteln und mit Blind-Injection-Techniken Zugangsdaten Zeichen für Zeichen extrahieren. Bei CVE-2021-22911 extrahierten Forscher Admin-Passwort-Hashes und Token zum Zurücksetzen von Passwörtern aus Rocket.Chat-Instanzen.
• Integrität: Durch Operator-Injection und den Missbrauch direkter Abfragen können Angreifer Dokumente ändern, ersetzen oder löschen. Angehängte Abfragen können neue Datensätze einfügen oder bestehende Feldwerte überschreiben.
• Verfügbarkeit: Eine $where-Payload mit Endlosschleife kann eine MongoDB-Instanz auslasten und die Datenbank faktisch lahmlegen, ohne den Netzwerkverkehr zu überfluten.
• Die Umgehung der Authentifizierung gehört zu den am häufigsten dokumentierten Auswirkungen. Damit bietet NoSQL-Injection einen direkten Weg zum Erstzugriff auf öffentlich erreichbare Anwendungen.
• Risiken für die Lieferkette und nachgelagerte Systeme vergrößern bei Plattformprodukten den Wirkungsradius von NoSQL-Injection. Wenn eine Schwachstelle eine Plattform wie Rocket. Chat oder Parse Server kompromittiert, sind auch deren Mandanten und nachgelagerte Nutzer betroffen. Eine einzige Injection-Schwachstelle in einem Backend-as-a-Service-Produkt kann zahlreiche Anwendungen auf dieser Plattform gefährden. Aus einer Schwachstelle werden so viele kompromittierte Umgebungen.
• Regulatorische und Compliance-bezogene Folgen ergeben sich unmittelbar aus Verletzungen der Vertraulichkeit. Wenn NoSQL-Injection die Exfiltration personenbezogener Daten, Zugangsdaten oder Kundenkommunikation ermöglicht, müssen Unternehmen Meldepflichten nach Regelwerken wie DSGVO, HIPAA, PCI DSS und Datenschutzgesetzen einzelner US-Bundesstaaten erfüllen. Die Technik, bei der Daten Zeichen für Zeichen durch blinde Injection-Angriffe extrahiert werden, kann sensible Daten über längere Zeit unbemerkt abfließen lassen. Dieser langsame Datenabfluss bleibt leicht unentdeckt. Deshalb ist Früherkennung entscheidend.

• Remote-Code-Ausführung ist durch serverseitige JavaScript-Auswertung nachgewiesen. Der OWASP WSTG stellt fest: „Da JavaScript eine vollwertige Programmiersprache ist, können Angreifer damit nicht nur Daten manipulieren, sondern auch beliebigen Code ausführen.“ Eine Veröffentlichung des International Symposium on Digital Forensics and Security (ISDFS) von 2025 beschreibt das Risiko unverblümt: „Weil JavaScript so mächtig ist, kommt das Offenlegen einer solchen Schwachstelle dem Überreichen eines Maschinengewehrs an einen Schwerkriminellen gleich.“

Sicherheitsteams, die das Vorgehen der Angreifer kennen, können es in jeder Phase durchkreuzen. So läuft es ab.

So nutzen Angreifer NoSQL-Injection aus

Angreifer suchen und nutzen NoSQL-Injection nach einem strukturierten Vorgehen aus: von der Aufklärung über die Datenexfiltration bis hin zur Codeausführung.

Phase 1: Eingabevektoren finden

Der Angreifer identifiziert Parameter, die an ein NoSQL-Backend übergeben werden: URL-Parameter, JSON-POST-Bodys, HTTP-Header und WebSocket-Nachrichten. Anschließend sendet er Testzeichen (' " \ ; { }) und beobachtet Fehlermeldungen oder Verhaltensänderungen, die Rückschlüsse auf die Datenbankinteraktion zulassen.

Phase 2: Bestätigung der Operator-Injektion

Bei einem Login-Endpoint ersetzt der Angreifer eine normale Zeichenfolge für Anmeldedaten durch einen $ne Operator:

Wenn die Anwendung eine erfolgreiche Anmeldung als anderer Benutzer meldet, ist die Operator-Injektion bestätigt. Der Angreifer kann auch den $gt (größer als) Operator zur weiteren Bestätigung testen:

Der $gt Operator gleicht mit einer leeren Zeichenfolge jeden nicht leeren Passwortwert ab. Gelingt die Anmeldung am Administratorkonto ohne gültiges Passwort, ist die Operator-Injektion erneut bestätigt.

Phase 3: Umgehung der Authentifizierung

Der Angreifer geht weiter und injiziert Operatoren in beide Felder:

Dies zielt gezielt auf privilegierte Konten ab und gibt den ersten Benutzer zurück, dessen Benutzername mit einem Listeneintrag übereinstimmt und dessen Passwort eine beliebige nicht leere Zeichenfolge ist.

Phase 4: Datenexfiltration

Mit $where als JavaScript-Injektion prüft der Angreifer, ob ein Feld existiert:

Wenn die Antwort einem bekannten gültigen Muster entspricht, existiert das Feld resetToken. Der Angreifer extrahiert dessen Wert anschließend Zeichen für Zeichen mittels boolescher Blind-Injektion. Dazu sendet er ein Regex-Muster wie {"resetToken":{"$regex":"^A"}} und beobachtet die HTTP-Antwort. Ein erfolgreicher Statuscode oder ein bestimmter Antworttext zeigt an, dass das Zeichen übereinstimmt. Eine andere Antwort zeigt an, dass es nicht übereinstimmt. Der Angreifer prüft nacheinander jede Zeichenposition und testet dabei jeweils alle möglichen Zeichen. Wie in CVE-2024-37405 dokumentiert, kann diese Extraktion durch wiederholte Anfragen mit unterschiedlichen Antworten erfolgen. Blind-Injektion ist damit ein praktikabler Angriff und keine rein theoretische Gefahr.

Phase 5: Privilegienausweitung und laterale Bewegung

Mit extrahierten Anmeldedaten oder Reset-Tokens verschafft sich der Angreifer Administratorzugriff. Von dort kann er zu Backend-Systemen vordringen, über eine Aggregation-Pipeline-Injektion mit $lookup oder $unionWith (von PortSwigger nominiert als eine der führenden Web-Hacking-Techniken) auf andere Collections zugreifen oder sich durch serverseitige Codeausführung dauerhaften Zugriff verschaffen. Eine Aggregation-Pipeline-Injektion mit $lookup hat schwerwiegende Folgen: Sie kann Daten aus Collections lesen, auf die die Anwendungsabfrage nie zugreifen sollte. So durchbricht sie Zugriffsgrenzen zwischen Collections und legt Daten aus der gesamten Datenbank offen.

Wechsel des Content-Type

Angreifer wechseln häufig zwischen application/x-www-form-urlencoded und application/json, um Injektionsstellen zu finden, die nur bei einem Content-Type bestehen. Diese Technik ist besonders wirksam gegen REST-APIs, die mehrere Formate verarbeiten.

Diese Angriffstechniken sind überall dort anwendbar, wo NoSQL-Datenbanken Benutzereingaben akzeptieren. Manche Anwendungen sind stärker gefährdet als andere.

Wer ist betroffen?

NoSQL-Injektion betrifft jede Anwendung, die benutzergesteuerte Eingaben ohne angemessene Typprüfung an eine NoSQL-Datenbank weitergibt. Bestätigten CVEs zufolge gehören folgende Anwendungskategorien zu den am stärksten gefährdeten:

• Authentifizierungssysteme: Login-Endpoints sind die in allen wichtigen Quellen dokumentierte typische Angriffsfläche.
• Plattformen für Teamarbeit: Für Rocket.Chat wurden über mehrere Jahre hinweg zahlreiche CVEs zu NoSQL-Injektionen veröffentlicht, darunter eine Schwachstelle, die sich vor der Authentifizierung ausnutzen lässt (CVE-2021-22911).
• Node.js/Express-Anwendungen mit Mongoose: Mongoose, ein Object Document Mapper (ODM), schafft unabhängig von den Kontrollen von MongoDB eigene Angriffspunkte für Injections auf der ORM-Ebene.
• Platform-as-a-Service-Backends: Parse Server (CVE-2022-24815, CVE-2026-30941) und Steedos Platform (CVE-2020-35666) zeigen, dass auch Backend-as-a-Service-Produkte betroffen sind.
• IoT und Netzwerkmanagement: Für die UniFi Network Application von Ubiquiti wurde eine vom Anbieter bestätigte CVE für NoSQL-Injection veröffentlicht, die eine Ausweitung von Berechtigungen ermöglicht.
• E-Commerce-Plattformen: Eine NoSQL-Injection in der Funktion zum Zurücksetzen von Passwörtern in AquilaCMS wurde als KRITISCH eingestuft (CVE-2024-48573).
• GraphQL-APIs: Nicht bereinigte GraphQL-Filterargumente, die direkt in MongoDB-Abfragen übernommen werden, schaffen einen oft übersehenen Angriffspunkt für Injections.

MongoDB ist weit verbreitet. Auch Node.js/Express wird häufig für die Backend-Entwicklung eingesetzt. Zusammen entsteht eine breite Angriffsfläche. NIST IR 8504 dokumentiert NoSQL-Injection offiziell als anerkannte Risikokategorie für US-Regierungssysteme. Das unterstreicht, dass das Risiko auch für Unternehmen gilt, nicht nur für Start-ups oder SaaS-Umgebungen.

GraphQL-APIs sind ein zunehmend häufiger Angriffsvektor: Filterargumente werden oft ohne explizite Positivliste direkt in MongoDB-Abfragen übernommen. Herkömmliche herkömmliche Web Application Firewalls (WAF)-Regeln, die sich auf SQL-typische Payloads konzentrieren, erfassen dieses Muster nur unzureichend.

Der gemeinsame Nenner ist nicht die Branche, sondern der Technologie-Stack. Wenn Sie MongoDB, Redis, CouchDB oder Elasticsearch mit Eingaben von Benutzern verwenden, ist Ihre Anwendung ein potenzielles Ziel. Das gilt besonders, wenn Sie JavaScript-Frameworks einsetzen, die Typen automatisch umwandeln. Die folgenden bestätigten Vorfälle zeigen, wie solche Angriffe in der Praxis ablaufen.

Beispiele aus der Praxis

Bestätigte CVEs und veröffentlichte Angriffsketten zeigen, wie NoSQL-Injection in produktiven Systemen ausgenutzt wird: auf Kollaborationsplattformen, E-Commerce-Plattformen, in Backend-as-a-Service-Produkten und in der Netzwerkinfrastruktur.

Rocket.Chat: Übernahme von Administratorkonten ohne vorherige Authentifizierung (CVE-2021-22911)

Untersuchungen von SonarSource zeigten, dass die Methode getPasswordPolicy() von Rocket.Chat ohne Authentifizierung aufgerufen werden konnte. Durch Einschleusen des MongoDB-Operators $regex in den Parameter für das Passwort-Reset-Token konnte ein Angreifer das Token Zeichen für Zeichen auslesen, indem er {"$regex":"^A"} sendete und unterschiedliche Antworten beobachtete.

Der bestätigte HackerOne-Bericht zeigte die Angriffskette: Angreifer konnten Administrator-Benutzernamen, E-Mail-Adressen, Passwort-Hashes und Reset-Tokens auslesen und schließlich ein Administratorkonto vollständig übernehmen.

@feathersjs/mongodb: Objekt-Injection über WebSocket (CVE-2026-29793)

Socket.IO-Clients konnten beliebige JavaScript-Objekte als Argument id an jede Feathers-Service-Methode senden. Die Transportschicht prüfte den Typ nicht. Bei Übergabe von {$ne: null} als Argument id stimmten alle Dokumente einer Collection mit der Abfrage überein. Die Schwachstelle wird unter CVE-2026-29793 geführt.

Ubiquiti UniFi: Ausweitung von Berechtigungen nach Authentifizierung (CVE-2026-22557)

Ubiquiti bestätigte in einem eigenen Sicherheitshinweis eine NoSQL-Injection-Schwachstelle in der UniFi Network Application, die nach der Authentifizierung eine Ausweitung von Berechtigungen ermöglichte. Jeder authentifizierte Benutzer konnte die Schwachstelle ausnutzen und mit einem Konto mit geringen Berechtigungen die vollständige administrative Kontrolle über die Netzwerkinfrastruktur erlangen.

Rocket.Chat Livechat: verkettete Injection (CVE-2024-37405)

Zwei separate NoSQL-Injektionspunkte wurden miteinander verkettet: Zunächst wurde ein Besucher-Token mittels $regex-Blindinjektion extrahiert, gefolgt von einer zweiten Injektion in den Parameter rid zum Auslesen aller Livechat-Nachrichten. Dieser Angriff ohne vorherige Authentifizierung legte Kommunikationsdaten aus dem Kundenkontakt offen.

AquilaCMS: kritische Injektion beim Zurücksetzen von Passwörtern (CVE-2024-48573)

AquilaCMS, eine Open-Source-E-Commerce-Plattform, erhielt für eine NoSQL-Injection-Schwachstelle in ihrer Funktion zum Zurücksetzen von Passwörtern die Einstufung KRITISCH (9.8). Ein nicht authentifizierter Angreifer konnte den Ablauf zum Zurücksetzen von Passwörtern manipulieren, indem er MongoDB-Operatoren in den Reset-Token-Parameter einschleuste und so die vorgesehene Validierung vollständig umging. Da E-Commerce-Shops auf AquilaCMS basieren, gefährdete eine erfolgreiche Ausnutzung Kundendaten, Zahlungsinformationen und Bestellverläufe. Die Schwachstelle erforderte keine Authentifizierung und ließ sich aus der Ferne über eine gewöhnliche HTTP-Anfrage ausnutzen. Damit war sie für jeden Angreifer mit Netzwerkzugriff auf den Shop zugänglich.

Parse Server: wiederkehrende Injektionsschwachstellen (CVE-2022-24815, CVE-2026-30941)

Parse Server, eine weit verbreitete Open-Source-Backend-as-a-Service-Plattform, war über mehrere Jahre hinweg wiederholt von NoSQL-Injektionsschwachstellen betroffen. CVE-2022-24815 kombinierte Prototype Pollution mit NoSQL-Injektion. Das zeigt, wie sich Schwachstellen auf JavaScript-Ebene und Datenbankinjektionen zu Angriffspfaden verbinden, die keine der beiden Schwachstellen allein eröffnet hätte. Jahre später zeigte CVE-2026-30941, dass die Plattform weiterhin Injektionsflächen aufwies, über die Token-Werte ohne Typvalidierung an Datenbankabfragen übergeben wurden. Backend-as-a-Service-Produkte sind besonders attraktive Ziele, weil eine einzige Schwachstelle jede auf der Plattform entwickelte Anwendung betrifft. Wird Parse Server kompromittiert, können darauf angewiesene mobile Apps, Webanwendungen und IoT-Backends derselben Gefährdung ausgesetzt sein.

Diese Vorfälle erstrecken sich über mehrere Jahre und Technologie-Stacks. NoSQL-Injektionen treten in Produktivsystemen immer wieder auf. Die Zeitleiste zeigt, wie lange dieses Muster bereits besteht.

Zeitleiste der NoSQL-Injektion

Die Häufung von CVEs im Jahr 2026 deutet auf ein wachsendes Interesse der Sicherheitsforschung an Node.js/MongoDB-Stacks hin. NoSQL-Injektionen rücken offenbar erneut in den Fokus. Deshalb hat ihre Erkennung Priorität. Die gute Nachricht: Die Anzeichen sind gut bekannt.

So erkennen Sie NoSQL-Injektionen

Um NoSQL-Injektionen aufzuspüren, kombinieren Sie statische Codeanalyse, dynamische Tests an aktiven Endpoints und Verhaltensüberwachung zur Laufzeit. So erkennen Sie auch Angriffe, die anderen Kontrollen entgehen.

Statische Analyse und Code-Review

Prüfen Sie Ihre Codebasis auf risikoreiche Muster. Markieren Sie alle Mongoose-.find(), .findOne() oder .populate()-Aufruf, der req.body, req.query oder req.params ohne Typprüfung direkt übergibt. Suchen Sie nach jeder Verwendung von $where mit benutzergesteuerten Eingaben, jeder Aggregationspipeline mit benutzergesteuerten Filterobjekten und jedem Endpunkt, der unbearbeitete JSON-Abfrageobjekte von Clients akzeptiert. Kennzeichnen Sie außerdem jede Verwendung von eval(), Function() oder Template-Literalen, die Benutzereingaben mit Abfragezeichenfolgen verketten. Prüfen Sie Aggregationspipelines mit $lookup oder $unionWith besonders sorgfältig, wenn sie benutzergesteuerte Collection-Namen oder Pipeline-Phasen verwenden. Dadurch können Zugriffsbeschränkungen auf Collection-Ebene umgangen werden.

Dynamische Tests

Folgen Sie der OWASP WSTG-INPV-05.6-Methodik:

1. Senden Sie die Fuzz-Zeichenfolge '"\{ ;$Foo} $Foo \xYZ`, um Einschleusungspunkte in der Syntax zu erkennen.
2. Senden Sie die Sonderzeichen ' " \ ; { }, um Einschleusungspunkte für Operatoren zu erkennen.
3. Nutzen Sie HTTP Parameter Pollution, um einen $where-Parameter einzuschleusen und die Fehlerantworten von MongoDB zu beobachten.
4. Testen Sie Unterschiede in den Antworten auf nachweislich wahre und nachweislich falsche Bedingungen, um Blind Injection aufzudecken.

Testen Sie auch WebSocket-Kanäle gezielt. CVE-2026-29793 zeigte, dass Socket.IO-Clients beliebige JavaScript-Objekte als Argumente für Servicemethoden senden und so sämtliche Prüfungen auf HTTP-Ebene umgehen konnten. Viele Scanner konzentrieren sich ausschließlich auf HTTP-Endpunkte und übersehen WebSocket-Einschleusungsflächen vollständig. Manuelle oder spezialisierte WebSocket-Tests schließen diese Lücke bei Anwendungen, die auf Frameworks für Echtzeitkommunikation aufbauen.

Überwachung des Laufzeitverhaltens

Überwachen Sie Ihre Infrastruktur auf Verhaltensindikatoren einer erfolgreichen Ausnutzung:

• Datenbankdienstprozesse (mongod, redis-server), die unerwartete Kindprozesse oder Shells starten
• Ungewöhnliche Abfragemuster mit MongoDB-Operatorsyntax ($where, $regex, $ne, $gt) in Anwendungsprotokollen
• CPU-Auslastungsspitzen auf MongoDB-Servern ohne entsprechende legitime Abfragelast
• Passwortzurücksetzungs-Endpunkte, die in Token-Feldern Objekte statt Zeichenfolgen empfangen
• Unterschiedliche Antwortzeiten bei öffentlich erreichbaren Endpunkten, die auf eine zeitbasierte Blind Injection hindeuten

Tools für Penetrationstests

Mit speziellen Tools prüfen Sie bei Sicherheitsbewertungen auf NoSQL-Injection:

• NoSQLMap: Open-Source-Tool, speziell für Tests auf NoSQL-Injection und deren Ausnutzung entwickelt
• nosqli: Kommandozeilen-Tool zur automatisierten Erkennung von NoSQL-Injection
• Burp Suite: Manuelle Tests mit den Modulen Repeater und Intruder sowie Erweiterungen für automatisierte Tests von NoSQL-Payloads
• OWASP ZAP: Aktive Scanregeln für NoSQL-Endpunkte

Zu wissen, wo Sie suchen müssen, ist die halbe Herausforderung. Die andere Hälfte besteht darin, Schutzmaßnahmen zu entwickeln, die eine Ausnutzung von vornherein verhindern.

So verhindern Sie NoSQL-Injection

Verhindern Sie NoSQL-Injection, indem Sie für alle Benutzereingaben strikte Typen durchsetzen, bevor diese die Datenbankschicht erreichen. Die folgenden Schutzmaßnahmen adressieren jede zuvor identifizierte Ursache, von der Typumwandlung auf Framework-Ebene bis zur Umgehung der ORM-Schicht.

Erzwingen Sie Typprüfungen vor der Abfrageerstellung

Weisen Sie jedes Eingabefeld zurück, das keinen skalaren Wert (Zeichenfolge, Zahl, boolescher Wert) enthält, bevor es Ihr ORM oder Ihren Datenbanktreiber erreicht. Explizite Typumwandlung ist die wirksamste Einzelmaßnahme:

Entfernen oder verwerfen Sie MongoDB-Operatorschlüssel

Prüfen Sie alle Schlüssel in req.body, req.query und req.params auf das $-Präfix und weisen Sie entsprechende Schlüssel zurück, bevor sie die Datenbankschicht erreichen. Verwenden Sie key.startsWith('$') zur Prüfung statt regulärer Ausdrücke, für die Umgehungsmöglichkeiten bekannt sind, wie in CVE-2021-22910 dokumentiert.

Deaktivieren Sie serverseitiges JavaScript

Verwenden Sie --noscripting oder set security.javascriptEnabled: false in Ihrer MongoDB-Konfiguration. Damit entfällt die $where-Angriffsfläche vollständig. Bevorzugen Sie $expr und typisierte Query-Builder für bedingte Logik.

Verwenden Sie Frameworks zur Schemavalidierung

Validieren Sie Datentypen frühzeitig im Anfragezyklus mit Bibliotheken wie Joi, Ajv oder Zod. Sie weisen Arrays oder Objekte zurück, wenn skalare Werte erwartet werden, und stoppen Operator-Injection, bevor sie die Datenbank erreicht.

Mongoose- und ORM-Versionen festlegen, Sicherheitshinweise verfolgen

Schwachstellen auf ORM-Ebene können sowohl Kontrollen auf Anwendungsebene als auch auf Datenbankebene vollständig umgehen. CVE-2024-53900 und CVE-2025-23061 zeigten, dass die Mongoose-Funktion populate().match selbst dann ausgenutzt werden konnte, wenn serverseitiges JavaScript in MongoDB deaktiviert war. CVE-2025-23061 war eine unvollständige Behebung von CVE-2024-53900. Das zeigt, dass Patches unzureichend sein können und unabhängig überprüft werden müssen.

Abonnieren Sie Sicherheitshinweise für Mongoose und andere ODM-/ORM-Bibliotheken, legen Sie Abhängigkeitsversionen ausdrücklich fest und prüfen Sie vor dem Schließen Ihres Tickets zur Schwachstellenbehebung, ob jeder Sicherheitspatch die dokumentierte Schwachstelle vollständig behebt.

Akzeptieren Sie niemals rohe JSON-Abfragen von Clients

Das OWASP Cheat Sheet stellt ausdrücklich fest: "Akzeptieren Sie keine rohen JSON-Abfragen von Clients." Eine Payload wie { "$where": "this.balance > 0" } kann, wenn sie von einem Client gesendet wird, zur Ausführung von Code aus der Ferne oder zur Überlastung der CPU führen.

Datenbank nach dem Prinzip der geringsten Rechte konfigurieren

Verwenden Sie dedizierte Datenbankkonten für Anwendungen mit minimalen Berechtigungen. Stellen Sie niemals eine Verbindung mit Root- oder Admin-Zugangsdaten her. Machen Sie Datenbankports und Admin-Konsolen nicht über das öffentliche Internet zugänglich.

Wire Object Check aktiviert lassen

Die MongoDB-Einstellung net.wireObjectCheck validiert alle Dokumente auf Ebene des Wire-Protokolls. Sie ist standardmäßig aktiviert. Deaktivieren Sie sie niemals.

GraphQL-Filter absichern

Verarbeiten Sie GraphQL-Filterargumente anhand einer expliziten Positivliste. Übernehmen Sie nicht vertrauenswürdige Objekte niemals direkt in MongoDB- oder Mongoose-Abfragefilter.

Starke Kontrollen auf Anwendungsebene verkleinern die Angriffsfläche. Sie können sie nicht vollständig beseitigen. Mehrschichtige Erkennung und Reaktion decken ab, was dennoch durchkommt.

Tools zur Erkennung und Prävention

Eine mehrschichtige Verteidigung gegen NoSQL-Injection kombiniert Kontrollen auf Anwendungsebene, Testtools und Laufzeitüberwachung.

• Anwendungsseitige Schutzmaßnahmen umfassen Bibliotheken zur Eingabevalidierung (Joi, Ajv, Zod), Schutzmechanismen auf ORM-Ebene (Mongoose-Schemavalidierung, explizite Typkonvertierung) und die integrierten Sicherheitskontrollen von MongoDB (--noscripting, wireObjectCheck, rollenbasierter Zugriff).
• Testtools wie NoSQLMap, nosqli, Burp Suite und OWASP ZAP prüfen während der Entwicklung und bei Penetrationstests auf NoSQL-Injection.
• WAFs bilden eine Schutzschicht am Netzwerkrand, die bekannte Injection-Muster blockieren kann. Allerdings arbeiten WAFs mit signaturbasierten Regeln und können neuartige Payloads, verschleierte Operatoren oder Injection über WebSocket-Kanäle nicht stoppen.
• Verhaltensüberwachung zur Laufzeit schließt die Lücke, die WAFs offenlassen. Neuartige Payloads, Schwachstellen auf ORM-Ebene wie das Mongoose-Problem mit populate().match oder WebSocket-Kanäle, die WAFs nicht prüfen, können Kontrollen auf Anwendungsebene umgehen. Die Laufzeitüberwachung erkennt die Folgen einer erfolgreichen Injection: etwa Datenbankprozesse, die unerwartet Shells starten, ungewöhnliche Muster bei der JavaScript-Ausführung oder auffällige Abfragemengen. Dabei spielt es keine Rolle, wie die Payload eingeschleust wurde. Wenn eine Injection-Payload die signaturbasierte Prüfung umgeht und die Datenbank erreicht, ist das daraus resultierende auffällige Verhalten der zuverlässigste Hinweis auf eine Kompromittierung.

Wie unterstützt SentinelOne?

Die Prüfung von Payloads ist Aufgabe der WAF. SentinelOne überwacht, was danach geschieht. Es erkennt und stoppt die Verhaltensfolgen einer erfolgreichen NoSQL-Injection: Prozessanomalien, laterale Bewegungen und Aktivitäten nach der Ausnutzung, die Kontrollen auf Anwendungsebene übersehen.

Die Singularity™ Platform von SentinelOne umfasst Singularity AI SIEM, das Telemetriedaten von Endpunkten, Cloud-Workloads, Identitätssystemen und Drittanbieterquellen in einem einzigen Data Lake korreliert. Bei den MITRE ATT&CK-Evaluierungen 2024 erzielte die Singularity Platform eine Erkennungsrate von 100% ohne Verzögerungen und generierte 88% weniger Warnmeldungen als der Median. Weniger Warnmeldungen bedeuten, dass sich Ihr Team auf bestätigte Bedrohungen konzentrieren kann. Wenn ein NoSQL-Injection-Angriff von einer Webanwendung über einen Datenbankserver bis zum Diebstahl von Zugangsdaten reicht, verknüpft AI SIEM diese Ereignisse über verschiedene Angriffsflächen hinweg ohne manuelle Korrelation.

In Singularity Endpoint verknüpft die Storyline-Technologie fortlaufend Ereignisse zur Prozesserstellung, Netzwerkverbindungen, Dateiänderungen und die Nutzung von Anmeldedaten auf jedem geschützten Endpunkt zu nachvollziehbaren Ereignisketten. Bei einem Angriff, der über $where serverseitiges JavaScript ausführt, verknüpft Storyline automatisch den Webserver-Prozess, der die schädliche Anfrage empfängt, den Datenbankdienst mit ungewöhnlichem Verhalten, den gestarteten Interpreter-Prozess und etwaige untergeordnete Shell-Prozesse unter einer einzigen Storyline-ID. Benutzerdefinierte Regeln von Storyline Active Response (STAR) werden ausgelöst, wenn Datenbankprozesse wie mongod oder redis-server unerwartete untergeordnete Prozesse starten. Das ist ein verlässlicher verhaltensbasierter Indikator für eine erfolgreiche Befehlsinjektion.

Purple AI™ beschleunigt Untersuchungen durch Abfragen in natürlicher Sprache. Laut IDC identifizieren Kunden von Purple AI Bedrohungen 63% schneller und verkürzen die mittlere Behebungszeit (MTTR) um 55%. Sie können mit "Zeige mir alle Prozesse, die mongod in den letzten 24 Stunden gestartet hat" eine Abfrage stellen oder direkt auf MITRE ATT&CK-Techniken wie T1190 (Exploit Public-Facing Application) und T1059 (Command and Scripting Interpreter) verweisen. Die Auto Investigation-Funktion von Purple AI sammelt autonom Belege aus dem gesamten Stack, führt Bedrohungsdaten zusammen und erstellt vollständige Angriffszeitachsen. So dauern Untersuchungen statt Stunden nur noch Minuten.

Cloud Workload Security schützt cloudbasierte NoSQL-Datenbanken zur Laufzeit. Das Produkt überwacht das Verhalten von Workloads in Echtzeit und nutzt Verified Exploit Paths, um evidenzbasierte Erkenntnisse sichtbar zu machen. Sie erkennen, wenn eine NoSQL-Injektion gegen eine cloudbasierte MongoDB- oder Redis-Instanz zu Aktivitäten nach der Kompromittierung führt.

Für Unternehmen, die NoSQL-Datenbanken im großen Maßstab betreiben, schließen diese Funktionen die Lücke zwischen der Prävention auf Anwendungsebene und der Transparenz über Aktivitäten nach der Kompromittierung. 

Vereinbaren Sie eine Demo mit SentinelOne, um diese Funktionen in Aktion zu sehen.

Verwandte Schwachstellen

NoSQL-Injektionen haben gemeinsame Ursachen und Angriffsmuster mit mehreren verwandten Schwachstellenklassen:

• SQL-Injektion (CWE-89): Das Gegenstück bei relationalen Datenbanken. Beide nutzen eine unzureichende Trennung von Benutzereingaben und Datenbankabfragen aus. Die Möglichkeit, bei NoSQL-Injektionen prozeduralen Code auszuführen, erweitert die Auswirkungen jedoch von der Datenmanipulation bis zur Ausführung beliebigen Codes.
• Server-Side Request Forgery (SSRF): Redis-CRLF-Injektionen werden häufig mit SSRF kombiniert. Angreifer nutzen SSRF, um eine interne Redis-Instanz zu erreichen, und schleusen anschließend über CRLF-Sequenzen zusätzliche Befehle ein.
• Befehlsinjektion (CWE-78): Wenn eine NoSQL-Injektion über $where serverseitiges JavaScript ausführt, ähnelt die daraus resultierende Möglichkeit stark einer Betriebssystem-Befehlsinjektion.
• Prototype Pollution: CVE-2022-24815 in Parse Server kombinierte Prototype Pollution mit einer NoSQL-Injektion. Das zeigt, wie Schwachstellen auf der JavaScript-Ebene die Auswirkungen einer Datenbankinjektion verstärken.
• Cross-Site Scripting (XSS): Sowohl XSS als auch NoSQL-Injektionen entstehen durch unzureichende Eingabevalidierung. Unternehmen, die für eine der beiden Schwachstellen anfällig sind, weisen häufig systematische Mängel bei der Validierung auf, die sie auch für die andere anfällig machen.

Wenn Sie diese Zusammenhänge verstehen, können Sie Tests und Gegenmaßnahmen über verwandte Schwachstellenklassen hinweg priorisieren, statt jede einzeln zu betrachten. Die folgende Tabelle führt bestätigte CVEs für NoSQL-Injektionen als Referenz auf.