cve.bz

CAPEC-676

NoSQL Injection

High severityHigh likelihoodStandard pattern

An adversary targets software that constructs NoSQL statements based on user input or with parameters vulnerable to operator replacement in order to achieve a variety of technical impacts such as escalating privileges, bypassing authentication, and/or executing code.

On this page

NoSQL database calls are written in an application's programming language, via a custom API call, or formatted in a common convention (e.g., JSON, XML, etc.), any of which the adversary can exploit to achieve the aforementioned goals. NoSQL attacks usually result from improper sanitization and validation of data that originates from a user, either via special character or JavaScript injection. In both cases, the adversary crafts input strings so that when the target software constructs NoSQL statements based on the input, the resulting NoSQL statement performs actions other than those intended by the application. However, unlike traditional SQL Injection attacks, NoSQL injection attacks can also occur in instances where the application does not rely upon user input, as is the case in operator replacements. This entails the adversary overriding reserved NoSQL variable names with ones that have been modified with malicious functionality (e.g., $where in MongoDB). In all cases, depending on the NoSQL API and data model used, successful injection can cause information disclosure, data modification, and code execution at the application level.

Note: NoSQL Injection attacks are executed within a procedural language (e.g., C, C++, Perl), as opposed to the declarative SQL language itself. As a result, NoSQL injection attacks can potentially result in greater impacts than traditional SQL Injection attacks [REF-668].

Ask an AI about this attack pattern

ChatGPTClaudeGoogle AI Mode

Show the promptExplain the attack pattern CAPEC-676: NoSQL Injection: how it unfolds, what it needs and how to prevent and detect it in my systems. Use https://capec.mitre.org/data/definitions/676.html and https://cve.bz/cve/capec/676?via=ask-ai-copy, which lists recent CVEs with the weaknesses it exploits. Cite the sources.

Opens a third-party assistant; its answer is its own, not cve.bz's. The prompt holds only this attack pattern's id and public links.

How the attack unfolds

  1. Explore

    The attacker looks for a way in.

    1. [Survey target application] Due to the number of NoSQL databases available and the numerous language/API combinations of each, the adversary must first survey the target application to learn what technologies are being leveraged and how they interact with user-driven data.

      2 techniques
      • Determine the technology stack leveraged by the target application, such as the application server, drivers, frameworks, APIs, and databases being utilized.
      • Identify areas of the application that interact with user input and may be involved with NoSQL queries.

  2. Experiment

    They probe what they found.

    1. [Identify user-controllable input susceptible to injection] After identifying the technology stack being used and where user-driven input is leveraged, determine the user-controllable input susceptible to injection such as authentication or search forms. For each user-controllable input that the adversary suspects is vulnerable to NoSQL injection, attempt to inject characters or keywords that have special meaning in the given NoSQL database or language (e.g., "$ne" for MongoDB or "$exists" for PHP/MongoDB), or JavaScript that can be executed within the application. The goal is to create a NoSQL query with an invalid syntax.

      4 techniques
      • Use web browser to inject input through text fields or through HTTP GET parameters.
      • Use a web application debugging tool such as Tamper Data, TamperIE, WebScarab,etc. to modify HTTP POST parameters, hidden fields, non-freeform fields, etc.
      • Use network-level packet injection tools such as netcat to inject input
      • Use modified client (modified by reverse engineering) to inject input.

    2. [Experiment with NoSQL Injection vulnerabilities] After determining that a given input is vulnerable to NoSQL Injection, hypothesize what the underlying query looks like. Iteratively try to add logic to the query to extract information from the database, modify/delete information in the database, or execute commands on the server.

      3 techniques
      • Use public resources such as OWASP's "Testing for NoSQL Injection" [REF-668] or Null Sweep's "NoSQL Injection Cheatsheet" [REF-669] and try different approaches for adding logic to NoSQL queries.
      • Iteratively add logic to the NoSQL query and use detailed error messages from the server to debug the query.
      • Attempt an HTTP Parameter Pollution attack to replace language-specific keywords, such as "where" within PHP [CAPEC-460].

  3. Exploit

    They carry out the attack.

    1. [Exploit NoSQL Injection vulnerability] After refining and adding various logic to NoSQL queries, craft and execute the underlying NoSQL query that will be used to attack the target system.

      1 technique
      • Craft and Execute underlying NoSQL query

Prerequisites

  • Awareness of the technology stack being leveraged by the target application.

  • NoSQL queries used by the application to store, retrieve, or modify data.

  • User-controllable input that is not properly validated by the application as part of NoSQL queries.

  • Target potentially susceptible to operator replacement attacks.

Skills required

  • Low skill

    For keyword and JavaScript injection attacks, it is fairly simple for someone with basic NoSQL knowledge to perform NoSQL injection, once the target's technology stack has been determined.

  • Medium skill

    For operator replacement attacks, the adversary must also have knowledge of HTTP Parameter Pollution attacks and how to conduct them.

Resources required

  • None: No specialized resources are required to execute this type of attack.

Signs of an attack

  • Too many false or invalid queries to the database, especially those caused by malformed input.

  • Executed queries or commands that appear to malicious in nature or originating from an untrustworthy source.

Consequences

What a successful attack can lead to
ImpactAffectsNote
Modify DataIntegrity
Read DataConfidentiality
Execute Unauthorized CommandsConfidentiality, Integrity, AvailabilityRun Arbitrary Code
Gain PrivilegesConfidentiality, Access Control, Authorization

Mitigations

  • Strong input validation - All user-controllable input must be validated and filtered for illegal characters as well as relevant NoSQL and JavaScript content. NoSQL-specific keywords, such as $ne, $eq or $gt for MongoDB, must be filtered in addition to characters such as a single-quote(') or semicolons (;) based on the context in which they appear. Validation should also extend to expected types.

  • If possible, leverage safe APIs (e.g., PyMongo and Flask-PyMongo for Python and MongoDB) for queries as opposed to building queries from strings.

  • Ensure the most recent version of a NoSQL database and it's corresponding API are used by the application.

  • Use of custom error pages - Adversaries can glean information about the nature of queries from descriptive error messages. Input validation must be coupled with customized error pages that inform about an error without disclosing information about the database or application.

  • Exercise the principle of Least Privilege with regards to application accounts to minimize damage if a NoSQL injection attack is successful.

  • If using MongoDB, disable server-side JavaScript execution and leverage a sanitization module such as "mongo-sanitize".

  • If using PHP with MongoDB, ensure all special query operators (starting with $) use single quotes to prevent operator replacement attacks.

  • Additional mitigations will depend on the NoSQL database, API, and programming language leveraged by the application.

Weaknesses it exploits

  • CWE-943 Improper Neutralization of Special Elements in Data Query Logic
  • CWE-1286 Improper Validation of Syntactic Correctness of Input

Recent CVEs with these weaknesses

  1. 9.8CVE-2026-125120

    Mongoose is a MongoDB object modeling tool designed to work in an asynchronous environment. Prior to 6.13.11, 7.8.12, 8.24.3, and 9.9.2, Mongoose countDocuments() does not apply the configured sanitizeFilter query selector injection defens…

  2. 7.5CVE-2026-125119

    Mongoose is a MongoDB object modeling tool designed to work in an asynchronous environment. From 6.0.0 until 6.13.12, 7.8.13, 8.24.7, and 9.11.4, Mongoose stores the connection-level sanitizeFilter option in Connection.config, but Query.pr…

  3. 4.8CVE-2026-125109

    Rack is a modular Ruby web server interface. From 3.0 until 3.1.23 and 3.2.8, Rack::Request#host_with_port, #base_url, and #url can return an attacker-controlled invalid authority from Host, X-Forwarded-Host, or Forwarded: host= verbatim. …

  4. 8.7CVE-2026-123572

    Hickory-dns from 0.20.1 before 0.26.2 contains a denial of service vulnerability in the hickory-proto SVCB and HTTPS record presentation format parser, which panics on malformed alpn values. Attackers can supply untrusted zone files with u…

  5. 5.5CVE-2026-123791

    A vulnerability was detected in OpenBMB Internet of Agents up to 9d78e88e47160eb42ee1ee8538c05e1c2c47877a. This affects the function _primary_field_query of the file common/utils/milvus_utils.py of the component Agent Registry. The manipul…

  6. 7.5CVE-2026-85726

    Chartbrew is an open-source web application that can connect directly to databases and APIs and use the data to create charts. Prior to 5.2.3, a date-typed MongoDB variable placed inside a quoted query placeholder was inserted as an unesca…

  7. 6.9CVE-2026-123617

    Openwhyd before 1.65.1 contains a NoSQL injection vulnerability that allows unauthenticated attackers to manipulate user lookups by passing JSON objects in the id parameter. Attackers can send MongoDB query operators such as $ne or $gt to …

  8. 8.8CVE-2026-63214

    SuiteCRM is an open-source, enterprise-ready Customer Relationship Management (CRM) software application. Prior to 7.15.2 and 8.10.2, legacy REST methods append an authenticated caller's query parameter as a SQL WHERE clause after insuffic…

The newest records naming one of them. Each weakness's page lists them all.

Part of

Examples

The following examples primarily cite MongoDB, PHP, and NodeJS attacks due to their prominence and popularity…

The following examples primarily cite MongoDB, PHP, and NodeJS attacks due to their prominence and popularity. However, please note that these attacks are not exclusive to this NoSQL instance, programming language, or runtime framework.

Within NodeJS, Login Bypass attacks are possible via MongoDB if user-input is not properly validated and sanitized [REF-670].

//NodeJS with Express.js
  db.collection('users').find({
    "user": req.query.user,
    "password": req.query.password
  });

The above code works fine if the user were to submit a query like the following:

https://example.org/login?user=patrick&password=1234

But an adversary could submit a malicious query such as the below, which would be interpreted by the code as follows:

https://example.org/login?user=patrick&password[$ne]=

//NodeJS with Express.js
  db.collection('users').find({
    "user": bob,
    "password": {"&ne": ""}
  });

This will result in a Login Bypass attack, as the query will succeed for all values where Bob's password is not an empty string.

MongoDB instances are also vulnerable to JavaScript Injection Attacks when user input is not properly validat…

MongoDB instances are also vulnerable to JavaScript Injection Attacks when user input is not properly validated and sanitized.

//PHP with MongoDB
  db.collection.find({$where: function() {
    return (this.username == $username) } } );

If the user properly specifies a username, then this code will execute as intended. However, an adversary can inject JavaScript into the "$username" variable to achieve a NoSQL Injection attack as follows:

//PHP with MongoDB
  db.collection.find({$where: function() {
    return (this.username == 'foo'; sleep(5000) ) } } );

This will result in the server sleeping for 5 seconds if the attack was successful. An adversary could supply a larger value to deny service to the application.

If leveraging PHP with MongoDB, operator replacement attacks are possible if special query operators are not …

If leveraging PHP with MongoDB, operator replacement attacks are possible if special query operators are not properly addressed. The below example from OWASP's "Test for NoSQL Injection" displays a simple case of how this could occur.[REF-668]

db.myCollection.find({$where: function() {
  return obj.credits - obj.debits<0; } } );

Even though the above query does not depend on any user input, it is vulnerable to a NoSQL injection attack via operator replacement on the "$where" keyword. In this case, the adversary could exploit MongoDB in the following manner:

$where: function() { //arbitrary JavaScript here }

MITRE's words, unchanged: CAPEC-676 at MITRE. CAPEC is Copyright © 2007–2026, The MITRE Corporation, used under the CAPEC terms of use: “The MITRE Corporation (MITRE) hereby grants you a non-exclusive, royalty-free license to use Common Attack Pattern Enumeration and Classification (CAPEC™) for research, development, and commercial purposes. Any copy you make for such purposes is authorized provided that you reproduce MITRE’s copyright designation and this license in any such copy.” CAPEC and the CAPEC logo are trademarks of The MITRE Corporation. Credits. All attack patterns.