What Is NoSQL Injection? How It Works and How to Prevent It

What Is NoSQL Injection?

NoSQL injection is a vulnerability that lets attackers manipulate queries sent to NoSQL databases by inserting malicious operators, JavaScript code, or crafted syntax through unsanitized user input. Formally classified in the Common Weakness Enumeration (CWE) as CWE-943, "Improper Neutralization of Special Elements in Data Query Logic," it targets databases like MongoDB, Redis, Cassandra, and Elasticsearch, which use flexible, schema-less query languages instead of standard SQL.

A successful exploit reaches far past a single bad query. An attacker can bypass authentication entirely, extract sensitive data character by character, modify records, trigger denial-of-service conditions, or execute arbitrary code on the server. As the OWASP WSTG notes, "the potential impacts are greater than traditional SQL injection" because NoSQL injection payloads may execute within a procedural language like JavaScript, not only a declarative query language.

NoSQL databases now power everything from login systems and chat platforms to e-commerce catalogs and IoT management consoles. Their growing adoption, paired with a widespread misunderstanding that "no SQL means no injection," makes this vulnerability class a persistent risk. The myth is wrong, and attackers count on it. 

Before examining how NoSQL injection works in practice, it helps to understand where it sits in the standard vulnerability classification frameworks.

OWASP Classification

OWASP classifies NoSQL injection under the Injection category in both the 2021 and 2025 Top 10. It shares a risk family with SQL injection but carries a different root-cause classification that affects how you test for it and report it.

The key distinction is the CWE mapping. Traditional SQL injection falls under CWE-89 (Improper Neutralization of Special Elements used in an SQL Command), while NoSQL injection maps to CWE-943 (Improper Neutralization of Special Elements in Data Query Logic). CWE-943 covers query languages beyond SQL, including MongoDB's Binary JSON (BSON) operators, Redis protocol commands, and CouchDB's REST-based queries.

If your security testing program or compliance reporting tracks only CWE-89, NoSQL injection findings may be miscategorized or missed entirely. Align your tooling and taxonomy to CWE-943, and the blind spot closes. 

With the classification set, the next step is understanding the specific mechanics attackers use to exploit NoSQL query interfaces.

How Does NoSQL Injection Work?

NoSQL injection exploits the gap between what your application expects from user input and what it actually receives. Where SQL injection targets a universal query language, NoSQL injection varies by database. MongoDB uses BSON/JSON query operators, Redis uses the Redis Serialization Protocol (RESP) wire protocol, and CouchDB exposes an HTTP REST API. Each database presents a different attack surface, but the core principle remains the same: user-controlled data enters a query without proper validation and changes the query's logic.

Operator injection: the most common pattern

In a typical MongoDB-backed Node.js application, a login endpoint might construct a query like this:

A legitimate request sends {"username":"admin","password":"secret"}. But an attacker can submit:

The $ne (not equal) operator tells MongoDB to return all users whose username and password are not equal to "invalid", which matches every valid account. Authentication is bypassed in a single request, with no brute-forcing required.

JavaScript injection via $where

When applications pass user input into MongoDB's $where operator or functions like mapReduce, $accumulator, or $function, the database evaluates it as server-side JavaScript. An attacker who injects a busy-loop payload can lock the MongoDB instance and cause a denial-of-service. Beyond data access, arbitrary JavaScript execution can lead to remote code execution on the database server.

Blind extraction

When the application does not return query results directly, attackers use boolean-based or timing-based techniques to extract data one character at a time. By submitting regex patterns like password[$regex]=^a and observing whether the response differs from a known-false condition, an attacker can reconstruct passwords, tokens, and other secrets without ever seeing a direct data leak.

Redis command injection via CRLF

In RESP, commands are separated by carriage return and line feed (CRLF) sequences (\r\n). When an application concatenates user input into Redis protocol-level commands without sanitization, an attacker can inject CRLF sequences to terminate the current command and piggyback unauthorized commands onto the same connection.

Redis stores data in key-value pairs, and injected commands like SET, GET, and CONFIG can read sensitive data, overwrite keys, or reconfigure the server entirely. This technique is frequently chained with Server-Side Request Forgery (SSRF), where the attacker uses an SSRF vulnerability to reach an internal Redis instance that is not exposed to the public internet, then injects piggybacked commands through the SSRF channel.

HTTP API injection in CouchDB

CouchDB exposes a REST/HTTP API, meaning all database operations occur through standard HTTP requests with JSON payloads. Injection occurs when an application passes unsanitized user input into CouchDB query parameters, view definitions, or Mango selector objects.

Because CouchDB uses MapReduce views written in JavaScript, it presents a server-side execution risk similar to MongoDB's $where operator. An attacker who can influence the JavaScript executed within a MapReduce view gains the ability to run arbitrary code on the database server. CouchDB's replication function can also be abused through crafted HTTP requests to trigger SSRF against internal services.

Each NoSQL database, whether MongoDB's BSON operators, Redis's protocol-level CRLF injection, or CouchDB's REST-based API, presents its own distinct attack surface. Your NoSQL injection defenses must match each database's specific query interface.

These mechanics work across content types, transport layers, and frameworks. The root causes behind them repeat, and that repetition is where defenders gain leverage.

Causes of NoSQL Injection

NoSQL injection does not arise from a single coding mistake. It results from a combination of architectural assumptions, framework behaviors, and missing validation layers that compound at runtime.

Improper input validation and missing type enforcement

Your application may assume that a field like password will always arrive as a string, but HTTP request bodies, JSON payloads, and URL-encoded parameters can carry objects and arrays. When Express.js body-parser receives password[$ne]=x, it automatically deserializes it into { password: { $ne: "x" } }, a MongoDB operator object, before application code ever touches it.

Dynamic Query Construction

When you assemble queries through string concatenation or interpolation rather than structured query objects, attackers can break the query syntax and inject new logic. The MongoDB forum confirms: "In most cases, external injections happen as a result of an unsafe concatenation of strings when creating queries."

Server-side JavaScript left enabled

MongoDB supports JavaScript execution through $where, mapReduce, $accumulator, and $function. The MongoDB checklist explicitly advises disabling server-side scripting with --noscripting when these operations are not in use. Leaving them enabled creates an attack surface for arbitrary code execution.

Framework-Level Type Coercion

PHP automatically converts username[$ne]=toto into ['username' => ['$ne' => 'toto']]. Express.js body-parser does the same for URL-encoded form data, deserializing password[$ne]=x into { password: { $ne: "x" } }, a MongoDB operator object, before the request ever reaches application code. These framework behaviors transform harmless-looking HTTP parameters into database operators without any deliberate action by the developer.

ORM-Layer Vulnerabilities

Even when MongoDB itself is hardened, your application's object-relational mapping (ORM) library can introduce injection surfaces. CVE-2024-53900 demonstrated that Mongoose's $where operator could be exploited via user-controlled inputs, and CVE-2025-23061, an incomplete fix for the first, showed that $where could still be bypassed through nesting under $or in Mongoose's populate().match feature, circumventing server-level protections entirely.

Disabled Wire Protocol Validation

MongoDB validates incoming documents at the wire protocol level through the net.wireObjectCheck setting. Disabling this removes a structural safety net that prevents malformed BSON from reaching the query engine.

These causes create an attack surface that spans from HTTP parsing to database execution, which translates directly into business risk.

Impact and Risk

NoSQL injection affects every dimension of the confidentiality, integrity, and availability (CIA) triad, often simultaneously.

• Confidentiality: Attackers can read arbitrary documents, enumerate field names, and extract credentials character by character using blind injection techniques. In CVE-2021-22911, researchers leaked admin password hashes and password reset tokens from Rocket.Chat instances.
• Integrity: Operator injection and raw query abuse allow attackers to modify, replace, or delete documents. Piggybacked queries can insert entirely new records or overwrite existing field values.
• Availability: A $where busy-loop payload can pin a MongoDB instance and effectively take the database offline without requiring network-level flooding.
• Authentication bypass is one of the most commonly documented impacts. This makes NoSQL injection a direct path to initial access for internet-facing applications.
• Supply chain and downstream risk amplifies the blast radius of NoSQL injection in platform products. When a vulnerability compromises a platform like Rocket. Chat or Parse Server, the impact extends to tenants and downstream users of that platform. A single injection flaw in a backend-as-a-service product can expose many applications built on that platform, turning one vulnerability into many breached environments.
• Regulatory and compliance consequences follow directly from confidentiality breaches. When NoSQL injection enables data exfiltration of personally identifiable information, credentials, or customer communications, organizations face breach notification requirements under frameworks like GDPR, HIPAA, PCI DSS, and state-level privacy laws. The character-by-character extraction technique used in blind injection attacks can silently exfiltrate sensitive data over extended periods. That slow drip is easy to miss, so early detection matters.

• Remote code execution is confirmed through server-side JavaScript evaluation. The OWASP WSTG states that "because JavaScript is a fully featured language, not only does this allow an attacker to manipulate data, but also to run arbitrary code." A paper from the 2025 International Symposium on Digital Forensics and Security (ISDFS) characterizes this risk bluntly: "Since JavaScript is powerful, exposing such a vulnerability can be compared to handing a machine gun to a top criminal."

Defenders who know the attacker's playbook can break it at every phase. Here is how that playbook runs.

How Attackers Exploit NoSQL Injection

Attackers follow a structured methodology to find and exploit NoSQL injection, moving from reconnaissance through data exfiltration or code execution.

Phase 1: Input Vector Discovery

The attacker identifies parameters passed to a NoSQL backend: URL parameters, JSON POST bodies, HTTP headers, and WebSocket messages. They submit fuzz characters (' " \ ; { }) and observe error messages or behavioral changes that reveal database interaction.

Phase 2: Confirming Operator Injection

Against a login endpoint, the attacker replaces a normal credential string with a $ne operator:

If the application returns a successful login for a different user, operator injection is confirmed. The attacker may also test the $gt (greater than) operator as an alternative confirmation:

The $gt operator with an empty string matches any non-empty password value. If the login succeeds for the admin account without a valid password, operator injection is doubly confirmed.

Phase 3: Authentication Bypass

The attacker escalates by injecting operators into both fields:

This targets privileged accounts specifically, returning the first user whose username matches the list and whose password is any non-empty string.

Phase 4: Data Exfiltration

Using $where JavaScript injection, the attacker probes for field existence:

If the response matches a known-valid pattern, the resetToken field exists. The attacker then extracts its value character by character using boolean-based blind injection. The technique works by submitting a regex pattern like {"resetToken":{"$regex":"^A"}} and observing the HTTP response. A success status code or a specific response body indicates the character matches, while a different response indicates it does not. The attacker iterates through each character position, testing the full character pool at each step. As documented in CVE-2024-37405, this extraction can operate through repeated differential requests, making blind injection a practical attack rather than a theoretical concern.

Phase 5: Privilege Escalation and Lateral Movement

With extracted credentials or reset tokens, the attacker gains administrative access. From there, they can pivot to backend systems, access other collections via aggregation pipeline injection using $lookup or $unionWith (nominated by PortSwigger as a top web hacking technique), or establish persistence through server-side code execution. Aggregation pipeline injection using $lookup is a high-impact technique because it can read from collections the application query was never intended to access, effectively breaking collection-level access boundaries and exposing data across the entire database.

Content-Type Switching

Attackers frequently switch between application/x-www-form-urlencoded and application/json to find injection points that exist in only one content type, a technique particularly effective against REST APIs that handle multiple formats.

These attack techniques apply wherever NoSQL databases accept user input. Some applications sit much closer to the line of fire than others.

Who Is Affected?

NoSQL injection affects any application that passes user-controlled input to a NoSQL database without proper type enforcement. Based on confirmed CVE evidence, the most exposed application categories include:

• Authentication systems: Login endpoints are the canonical attack surface documented across all major sources.
• Team collaboration platforms: Rocket.Chat accounts for multiple NoSQL injection CVEs across several years, including a pre-authentication vulnerability (CVE-2021-22911).
• Node.js/Express applications using Mongoose: Mongoose, an object document mapper (ODM), introduces injection surfaces at the ORM layer, independent of MongoDB's own controls.
• Platform-as-a-service backends: Parse Server (CVE-2022-24815, CVE-2026-30941) and Steedos Platform (CVE-2020-35666) demonstrate exposure in backend-as-a-service products.
• IoT and network management: Ubiquiti's UniFi Network Application received a vendor-confirmed NoSQL injection CVE enabling privilege escalation.
• E-commerce platforms: AquilaCMS received a CRITICAL rating for NoSQL injection in its password reset function (CVE-2024-48573).
• GraphQL APIs: Unsanitized GraphQL filter arguments that spread directly into MongoDB queries create an often-overlooked injection surface.

MongoDB is widely used, and Node.js/Express is also widely adopted for backend development. The combination creates a broad attack surface. NIST IR 8504 formally documents NoSQL injection as a recognized risk category for U.S. government systems, underscoring that this applies at the enterprise level, not only in startups or SaaS environments.

GraphQL APIs represent an increasingly common vector because filter arguments are often spread directly into MongoDB queries without an explicit allow-list, and this pattern is poorly covered by traditional traditional web application firewall (WAF) rules that focus on SQL-style payloads.

The common thread is not the industry but the technology stack. If you use MongoDB, Redis, CouchDB, or Elasticsearch with user-facing input, your application is a potential target, especially when you build on JavaScript frameworks that perform automatic type coercion. The following confirmed incidents show what exploitation looks like in practice.

Real-World Examples

Confirmed CVEs and published exploit chains show how NoSQL injection plays out in production systems across collaboration platforms, e-commerce, backend-as-a-service products, and network infrastructure.

Rocket.Chat: Pre-authentication admin takeover (CVE-2021-22911)

SonarSource research showed that Rocket.Chat's getPasswordPolicy() method could be called without authentication. By injecting MongoDB's $regex operator into the password reset token parameter, an attacker could extract the token character by character, sending {"$regex":"^A"} and observing differential responses.

The confirmed HackerOne report showed the attack chain: leaking admin usernames, email addresses, password hashes, and reset tokens, culminating in complete admin account takeover.

@feathersjs/mongodb: WebSocket object injection (CVE-2026-29793)

Socket.IO clients could send arbitrary JavaScript objects as the id argument to any Feathers service method. The transport layer performed no type checking. Sending {$ne: null} as the id matched every document in a collection. The vulnerability is tracked as CVE-2026-29793.

Ubiquiti UniFi: authenticated privilege escalation (CVE-2026-22557)

Ubiquiti's own advisory confirmed an authenticated NoSQL injection vulnerability in the UniFi Network Application that enabled privilege escalation. Any authenticated user could exploit the flaw to gain elevated access, turning a low-privilege account into full administrative control over network infrastructure.

Rocket.Chat Livechat: chained injection (CVE-2024-37405)

Two distinct NoSQL injection points were chained together: a visitor token extraction via $regex blind injection, followed by a second injection in the rid parameter to dump all Livechat messages. This pre-authentication attack exposed customer-facing communication data.

AquilaCMS: critical password reset injection (CVE-2024-48573)

AquilaCMS, an open-source e-commerce platform, received a CRITICAL (9.8) rating for a NoSQL injection vulnerability in its password reset function. An unauthenticated attacker could manipulate the password reset flow by injecting MongoDB operators into the reset token parameter, bypassing the intended validation logic entirely. Because AquilaCMS powers e-commerce storefronts, successful exploitation put customer account data, payment information, and order histories at risk. The vulnerability required no authentication and could be exploited remotely through a standard HTTP request, making it accessible to any attacker with network access to the storefront.

Parse Server: repeated injection vulnerabilities (CVE-2022-24815, CVE-2026-30941)

Parse Server, a widely used open-source backend-as-a-service platform, has experienced recurring NoSQL injection vulnerabilities across multiple years. CVE-2022-24815 combined prototype pollution with NoSQL injection, demonstrating how JavaScript-layer vulnerabilities compound with database injection to create exploitation paths that neither flaw would enable alone. Years later, CVE-2026-30941 revealed that the platform continued to have injection surfaces where token values were passed to database queries without type validation. Backend-as-a-service products are high-value targets because a single vulnerability affects every application built on the platform. When Parse Server is compromised, mobile apps, web applications, and IoT backends relying on it can share the same exposure.

These incidents span multiple years and technology stacks. NoSQL injection keeps resurfacing in production systems, and the timeline shows how long the pattern has run.

NoSQL Injection Timeline

The 2026 CVE cluster signals increasing researcher focus on Node.js/MongoDB stacks and suggests NoSQL injection may be drawing renewed attention rather than fading from view. That trajectory makes detection a priority. The good news is that the signals are well understood.

How to Detect NoSQL Injection

Finding NoSQL injection requires a combination of static code analysis, dynamic testing against live endpoints, and runtime behavioral monitoring that catches exploitation your other controls miss.

Static Analysis and Code Review

Review your codebase for high-risk patterns. Flag any Mongoose .find(), .findOne(), or .populate() call that directly passes req.body, req.query, or req.params without type enforcement. Look for any use of $where with user-controlled input, any aggregation pipeline incorporating user-controlled filter objects, and any endpoint accepting raw JSON query objects from clients. Additionally, flag any use of eval(), Function(), or template literals that concatenate user input into query strings. Aggregation pipelines using $lookup or $unionWith with user-controlled collection names or pipeline stages should receive particular scrutiny, as these can break collection-level access boundaries.

Dynamic Testing

Follow the OWASP WSTG-INPV-05.6 methodology:

1. Submit the fuzz string '"\{ ;$Foo} $Foo \xYZ` to identify syntax injection points.
2. Submit special characters ' " \ ; { } to identify operator injection points.
3. Use HTTP Parameter Pollution to inject a $where parameter and observe MongoDB error responses.
4. Test boolean response differentials using known-true versus known-false conditions to uncover blind injection.

You should also test WebSocket channels specifically. CVE-2026-29793 demonstrated that Socket.IO clients could send arbitrary JavaScript objects as service method arguments, bypassing all HTTP-layer inspection. Many scanners focus exclusively on HTTP endpoints and miss WebSocket injection surfaces entirely. Manual or specialized WebSocket testing closes that gap for applications built on real-time communication frameworks.

Runtime Behavioral Monitoring

Monitor your infrastructure for behavioral indicators of successful exploitation:

• Database service processes (mongod, redis-server) spawning unexpected child processes or shells
• Unusual query patterns containing MongoDB operator syntax ($where, $regex, $ne, $gt) in application logs
• CPU spikes on MongoDB servers without corresponding legitimate query load
• Password reset endpoints receiving objects rather than strings in token fields
• Differential response times on public-facing endpoints that suggest timing-based blind injection

Penetration Testing Tools

Dedicated tools help you probe for NoSQL injection during assessments:

• NoSQLMap: Open-source tool built specifically for NoSQL injection testing and exploitation
• nosqli: Command-line tool for automated NoSQL injection discovery
• Burp Suite: Manual testing via Repeater and Intruder modules, with extensions for automated NoSQL payload testing
• OWASP ZAP: Active scan rules applicable to NoSQL endpoints

Knowing where to look is half the challenge. Building defenses that prevent exploitation in the first place is the other half.

How to Prevent NoSQL Injection

Stopping NoSQL injection starts with enforcing strict types on all user input before it reaches your database layer. The defenses below address each root cause identified earlier, from framework-level type coercion to ORM-layer bypasses.

Enforce Type Checking Before Query Construction

Reject any input field that is not a scalar value (string, number, boolean) before it reaches your ORM or database driver. Explicit type coercion is the single most effective defense:

Strip or reject MongoDB operator keys

Check all keys in req.body, req.query, and req.params for the $ prefix and reject them before they reach the database layer. Use key.startsWith('$') checking rather than regex, which has known bypasses as documented in CVE-2021-22910.

Disable Server-Side JavaScript

Use --noscripting or set security.javascriptEnabled: false in your MongoDB configuration. This removes the $where attack surface entirely. Prefer $expr and typed query builders for conditional logic.

Use Schema Validation Frameworks

Enforce data type validation early in the request lifecycle using libraries like Joi, Ajv, or Zod. These reject arrays or objects where scalar values are expected, stopping operator injection before it reaches the database.

Pin Mongoose and ORM Versions, Monitor Advisories

ORM-layer vulnerabilities can bypass both application-level and database-level controls entirely. CVE-2024-53900 and CVE-2025-23061 demonstrated that Mongoose's populate().match feature could be exploited even when MongoDB server-side JavaScript was disabled. CVE-2025-23061 was an incomplete fix for CVE-2024-53900, showing that patches themselves may be insufficient and require independent verification.

Subscribe to security advisories for Mongoose and other ODM/ORM libraries, pin dependency versions explicitly, and validate that each security patch fully resolves the documented vulnerability before closing your remediation ticket.

Never accept raw JSON queries from Clients

The OWASP cheat sheet states explicitly: "Do not accept raw JSON queries from clients." A payload like { "$where": "this.balance > 0" } submitted from a client leads to remote code execution or CPU exhaustion.

Apply Least-Privilege Database Configuration

Use dedicated application database accounts with minimal permissions. Never connect with root or admin credentials. Do not expose database ports or admin consoles to the public internet.

Keep Wire Object Check Enabled

MongoDB's net.wireObjectCheck setting validates all documents at the wire protocol level. It is enabled by default. Never disable it.

Secure GraphQL Filters

Translate GraphQL filter arguments through an explicit allow-list. Never spread untrusted objects directly into MongoDB or Mongoose query filters.

Strong application-level controls shrink the attack surface. They cannot close it completely, and layered detection and response covers what slips through.

Tools for Detection and Prevention

A layered defense against NoSQL injection combines application-level controls, testing tools, and runtime monitoring.

• Application-layer defenses include input validation libraries (Joi, Ajv, Zod), ORM-level safeguards (Mongoose schema validation, explicit type casting), and MongoDB's built-in security controls (--noscripting, wireObjectCheck, role-based access).
• Testing tools like NoSQLMap, nosqli, Burp Suite, and OWASP ZAP probe for NoSQL injection during development and penetration testing cycles.
• WAFs provide a perimeter defense layer that can block known injection patterns. However, WAFs operate on signature-based rules and cannot stop novel payloads, obfuscated operators, or injection via WebSocket channels.
• Runtime behavioral monitoring fills the gap that WAFs leave open. Application-layer controls can be bypassed through novel payloads, ORM-layer vulnerabilities like the Mongoose populate().match issue, or WebSocket channels that WAFs do not inspect. Runtime monitoring observes the consequences of successful injection, such as database processes spawning unexpected shells, abnormal JavaScript execution patterns, or anomalous query volumes, regardless of how the payload was delivered. When an injection payload evades signature-based inspection and reaches the database, the resulting anomalous behavior becomes the most reliable indicator of compromise.

How can SentinelOne Help?

Payload inspection is the WAF's job. SentinelOne watches what happens next, and it finds and stops the behavioral consequences of successful NoSQL injection: the process anomalies, lateral movement, and post-exploitation activity that application-layer controls miss.

SentinelOne’s Singularity™ Platform includes Singularity AI SIEM, which correlates telemetry across endpoints, cloud workloads, identity systems, and third-party sources within a single data lake. In the 2024 MITRE ATT&CK Evaluations, the Singularity Platform achieved 100% detection with zero delays while generating 88% fewer alerts than the median. Less noise means your team can focus on confirmed threats. When a NoSQL injection attack chains from a web application to a database server to credential theft, AI SIEM links those events across surfaces without manual correlation.

Within Singularity Endpoint, Storyline technology continuously stitches together process creation events, network connections, file modifications, and credential usage on each protected endpoint into coherent provenance chains. For a $where-based server-side JavaScript execution attack, Storyline autonomously chains the web server process receiving the malicious request, the database service behaving anomalously, the spawned interpreter process, and any child shell, all linked under a single Storyline ID. Storyline Active Response (STAR) custom rules fire when database processes like mongod or redis-server spawn unexpected child processes, a high-fidelity behavioral indicator of successful command injection.

Purple AI™ accelerates investigation through natural language queries. According to IDC, Purple AI customers achieve 63% faster threat identification and a 55% reduction in mean time to remediate (MTTR). You can ask "show me all processes spawned by mongod in the last 24 hours" or reference MITRE ATT&CK techniques like T1190 (Exploit Public-Facing Application) and T1059 (Command and Scripting Interpreter) directly. Purple AI's Auto Investigation capability autonomously gathers cross-stack evidence, synthesizes threat data, and constructs complete attack timelines, shrinking investigations that once took hours into minutes.

Cloud Workload Security provides runtime protection for cloud-hosted NoSQL databases. It monitors workload behavior in real time and uses Verified Exploit Paths to surface evidence-based findings. You see when a NoSQL injection against a cloud-hosted MongoDB or Redis instance leads to post-exploitation activity.

For organizations running NoSQL databases at scale, these capabilities close the gap between application-level prevention and post-exploitation visibility. 

Request a SentinelOne demo to see these capabilities in action.

Related Vulnerabilities

NoSQL injection shares root causes and attack patterns with several related vulnerability classes:

• SQL Injection (CWE-89): The relational database counterpart. Both exploit improper neutralization of user input in database queries, but NoSQL injection's procedural language execution capability extends the impact beyond data manipulation to arbitrary code execution.
• Server-Side Request Forgery (SSRF): Redis CRLF injection is frequently chained with SSRF. An attacker uses SSRF to reach an internal Redis instance and then injects piggybacked commands via CRLF sequences.
• Command Injection (CWE-78): When NoSQL injection achieves server-side JavaScript execution through $where, the resulting capability closely mirrors OS command injection.
• Prototype Pollution: CVE-2022-24815 in Parse Server combined prototype pollution with NoSQL injection, demonstrating how JavaScript-layer vulnerabilities compound with database injection.
• Cross-Site Scripting (XSS): Both XSS and NoSQL injection stem from insufficient input validation. Organizations vulnerable to one frequently have systemic validation weaknesses that expose them to the other.

Understanding these relationships helps you prioritize testing and remediation across related vulnerability classes rather than treating each one in isolation. The following table lists confirmed NoSQL injection CVEs for reference.