CVE-2026-42334

What it actually does

This flaw is an input validation weakness in Mongoose’s sanitizeFilter protection. When sanitizeFilter is enabled, Mongoose is intended to neutralize user-supplied MongoDB query operators by wrapping them in $eq. Affected versions fail to recursively sanitize the $nor logical operator. Because $nor accepts an array, attacker-controlled objects inside that array can contain operators such as $ne, $gt, or $regex without being rewritten. The practical result is a MongoDB query selector injection condition: an unauthenticated remote attacker may be able to alter application query logic and retrieve records they should not be able to access. The CVSS vector indicates high confidentiality impact, with no direct integrity or availability impact.

Why it matters to the business

Applications that accept user-controlled search, filter, login, lookup, or API query parameters and pass them into Mongoose with sanitizeFilter enabled may expose sensitive data despite relying on Mongoose’s built-in sanitization. The main business risk is unauthorized disclosure of customer, user, account, or operational records through manipulated queries. The issue is not currently listed in CISA KEV, has no known ransomware association, and has low EPSS at publication age 90 days, but Mongoose is widely used in Node.js ecosystems, so vulnerable dependencies may be present indirectly in many applications.

How an attack unfolds

An attacker first identifies an application endpoint that accepts structured query input, such as JSON request bodies, query string filters, search parameters, or API filter objects. If that input is passed into a Mongoose query while relying on sanitizeFilter for protection, the attacker supplies a $nor clause containing an array of objects with MongoDB operators such as $ne, $gt, or $regex. In vulnerable Mongoose versions, the sanitization logic does not treat $nor like other recursive logical operators, so malicious operators inside the $nor array remain active. MongoDB then evaluates the attacker-controlled selector, potentially broadening or changing the query condition and returning records the attacker should not be authorized to view. Exploitation depends on application behavior: the vulnerability is most impactful where user input is directly mapped into find, findOne, count, aggregate-adjacent filtering, authentication lookups, or authorization-sensitive data retrieval.

How to fix it

Upgrade Mongoose to a fixed version appropriate for the major release in use: 6.13.9 or later for 6.x, 7.8.9 or later for 7.x, 8.22.1 or later for 8.x, and 9.1.6 or later for 9.x. Regenerate and redeploy lockfiles so production actually uses the patched transitive version. Do not rely only on sanitizeFilter for authorization-sensitive logic: explicitly allowlist permitted filter fields, reject keys beginning with $, reject nested operator objects from untrusted input unless intentionally supported, and enforce authorization constraints server-side outside attacker-controlled filters. Where immediate upgrade is not possible, add application-level validation that blocks $nor and other MongoDB operator keys in user-controlled request data, especially inside arrays and nested objects.

How to confirm the fix worked

Confirm dependency versions using package manager output and lockfiles, for example npm ls mongoose, yarn why mongoose, pnpm why mongoose, package-lock.json, yarn.lock, or pnpm-lock.yaml. Verify all deployed artifacts use Mongoose 6.13.9, 7.8.9, 8.22.1, 9.1.6, or newer. Add a regression test against endpoints accepting filters by submitting nested $nor payloads containing operators such as $ne, $gt, or $regex and confirming they are rejected, treated as literal values, or otherwise cannot alter query semantics. Review code paths that pass req.query, req.body, parsed JSON filters, or GraphQL arguments directly into Mongoose query methods. If dependency scanning is used, ensure software composition analysis flags mongoose versions below the fixed releases.

Typical attack path

1. Identify a Node.js application or API that uses Mongoose and accepts client-controlled filter/search/login/query parameters.
2. Submit benign requests to understand whether nested JSON-style filters are accepted and reflected in query results.
3. Craft a payload using the $nor operator with an array containing MongoDB operators such as $ne, $gt, or $regex.
4. Send the crafted payload to an endpoint that passes user input into a Mongoose query while sanitizeFilter is enabled.
5. Observe whether the response returns broader, unexpected, or unauthorized records.
6. Iterate on injected query operators to bypass intended filters or extract sensitive data within the limits of the application response.

How to detect it

To assess prior exploitation, review HTTP access logs, API gateway logs, WAF logs, application request logs, and structured audit logs for requests containing MongoDB operator syntax in user-controlled parameters. Focus on endpoints that accept search, filter, login, lookup, reporting, or JSON query bodies. Look for literal or URL-encoded occurrences of $nor combined with nested operators such as $ne, $gt, $gte, $lt, $lte, $regex, $in, or $exists. Because successful exploitation may only appear as abnormal data access, correlate suspicious requests with unusual response sizes, unexpectedly broad result sets, high-volume enumeration, repeated filter experimentation, or access to records outside normal user authorization patterns. If request bodies are not logged, inspect WAF telemetry, API gateway samples, error logs, application debug logs, and MongoDB profiler/audit logs for query selectors containing $nor arrays with nested operator objects. There are no known public threat actors, ransomware campaigns, or KEV-listed exploitation associated with this CVE from the supplied intelligence.

• $nor
• %24nor
• \u0024nor
• "$nor"
• '$nor'
• $nor[$ne]
• %24nor%5B%24ne%5D
• "$nor":[{"$ne"
• "$nor":[{"$gt"
• "$nor":[{"$gte"
• "$nor":[{"$lt"
• "$nor":[{"$lte"
• "$nor":[{"$regex"
• "$nor":[{"$in"
• "$nor":[{"$exists"
• %22%24nor%22%3A%5B%7B%22%24ne%22
• %22%24nor%22%3A%5B%7B%22%24gt%22
• %22%24nor%22%3A%5B%7B%22%24regex%22

What your security team should do

• Prioritize inventory of Node.js services that depend on mongoose, including transitive dependency paths and container images.
• Upgrade affected applications to Mongoose 6.13.9, 7.8.9, 8.22.1, 9.1.6, or newer, matching the deployed major version.
• Search application code for direct use of user-controlled input in Mongoose query methods such as find, findOne, countDocuments, exists, update query filters, and delete query filters.
• Implement allowlist-based validation for all externally supplied query/filter parameters and block MongoDB operator keys from untrusted input by default.
• Add automated tests for selector-injection payloads using $nor with nested $ne, $gt, and $regex operators.
• Review access logs and application logs for suspicious requests containing encoded or literal $nor operator payloads, especially against search, login, lookup, and API filtering endpoints.
• Monitor advisories and package manager audit feeds, but treat this as a code-path-dependent exposure rather than assuming every installed vulnerable version is exploitable.