CVE-2026-125119: Connection-Level Filter Sanitization Bypass in Mongoose ODM

Mongoose is the standard Object Data Modeling (ODM) library for MongoDB and Node.js. It provides schema validation, type casting, and query building abstractions over the native MongoDB driver. Because MongoDB queries are structured as BSON/JSON documents rather than parameterized strings, web applications that parse JSON request bodies (e.g., via express.json()) or nested query strings directly into Mongoose query methods expose an attack surface for NoSQL query selector injection.

To mitigate this class of vulnerability, Mongoose 6.0.0 introduced the sanitizeFilter option. When enabled, sanitizeFilter recursively inspects query filter objects and neutralizes properties beginning with the $ prefix (such as $ne, $gt, $in, $regex, or $where) by wrapping them in an explicit $eq operator. This forces MongoDB or Mongoose's schema caster to evaluate the injected object as a literal value rather than a query operator.

CVE-2026-125119 (GHSA-gg4r-jv3p-qx3c), classified under CWE-943 (Improper Neutralization of Special Elements in Data Query Logic), occurs because Mongoose fails to propagate or inspect the sanitizeFilter setting when configured at the database connection level. When a developer passes { sanitizeFilter: true } into mongoose.connect() or mongoose.createConnection(), the configuration is stored in Connection.config, whereas the query execution pipeline exclusively checks Connection.options and the global Mongoose instance.

Consequently, any application relying on connection-level configuration to neutralize untrusted query inputs executes queries without sanitization. Even though inspecting the connection state via conn.get('sanitizeFilter') returns true, all read, write, and delete operations bound to that connection remain exposed to operator injection, enabling unauthenticated authentication bypass and arbitrary document disclosure.

The root cause of CVE-2026-125119 is a state storage discrepancy between how connection options are initialized in NativeConnection and how they are retrieved in Query and cast. In Mongoose, sanitizeFilter can be configured at three distinct hierarchy levels: globally via mongoose.set('sanitizeFilter', true), per-connection via mongoose.connect(uri, { sanitizeFilter: true }), or per-query via .sanitizeFilter(true).

When a connection is instantiated through mongoose.connect(uri, options) or mongoose.createConnection(uri, options), Mongoose invokes NativeConnection.prototype.createClient(). During this initialization routine, Mongoose separates driver-level MongoDB options from Mongoose-specific connection configuration settings. The sanitizeFilter property is extracted and stored inside the connection's this.config object (this.config.sanitizeFilter), leaving this.options.sanitizeFilter undefined.

When a query is executed on a model bound to that connection, Mongoose invokes Query.prototype._castConditions() and Query.prototype.cast() in lib/query.js. Prior to the patch, both methods resolved the active sanitizeFilter setting by checking this.model.db.options.sanitizeFilter (the connection options), this.model.base.options.sanitizeFilter (the global Mongoose options), and this._mongooseOptions.sanitizeFilter (the per-query options). Neither method checked this.model.db.config.sanitizeFilter.

Because this.model.db.options.sanitizeFilter was undefined, the conditional check skipped calling sanitizeFilter(this._conditions). Additionally, a secondary defect existed in lib/cast.js: when casting an array value supplied for a non-array schema path (such as passing password: ['secret'] to a String field), Mongoose implicitly converts the filter into a { $in: ['secret'] } operator query. Because Query.prototype.cast() failed to pass the connection's sanitizeFilter flag down into the opts object consumed by cast(), this implicit $in selector conversion also bypassed sanitization.

The vulnerability was addressed across four release branches (6.x, 7.x, 8.x, and 9.x) by updating lib/query.js and lib/cast.js to include model.db.config in the option resolution chain and blocking implicit $in array casting when sanitizeFilter is active.

In lib/query.js, Query.prototype._castConditions and Query.prototype.cast were modified to check this.model?.db.config?.sanitizeFilter first using nullish coalescing (??) before falling back to db.options, base.options, and _mongooseOptions:

// File: lib/query.js
Query.prototype._castConditions = function() {
  // BEFORE (Vulnerable): Checked db.options, ignoring db.config
  // let sanitizeFilterOpt = undefined;
  // if (this.model?.db.options?.sanitizeFilter != null) {
  //   sanitizeFilterOpt = this.model.db.options.sanitizeFilter;
  // } else if (this.model?.base.options?.sanitizeFilter != null) {
  //   sanitizeFilterOpt = this.model.base.options.sanitizeFilter;
  // } else {
  //   sanitizeFilterOpt = this._mongooseOptions.sanitizeFilter;
  // }
 
  // AFTER (Patched): Prioritizes model.db.config.sanitizeFilter
  const sanitizeFilterOpt = this.model?.db.config?.sanitizeFilter ??
    this.model?.db.options?.sanitizeFilter ??
    this.model?.base.options.sanitizeFilter ??
    this._mongooseOptions.sanitizeFilter;
 
  if (sanitizeFilterOpt) {
    sanitizeFilter(this._conditions);
  }
  // ...
};

Similarly, Query.prototype.cast in lib/query.js was updated so that the resolved sanitizeFilter boolean is attached to the opts object passed into cast(model.schema, obj, opts, this):

// File: lib/query.js
Query.prototype.cast = function(model, obj) {
  obj || (obj = {});
  model || (model = this.model);
 
  const opts = { strict: this.options.strict };
  if ('strictQuery' in this._mongooseOptions) {
    opts.strictQuery = this._mongooseOptions.strictQuery;
  }
 
  // BEFORE (Vulnerable): Only checked per-query _mongooseOptions
  // if ('sanitizeFilter' in this._mongooseOptions) {
  //   opts.sanitizeFilter = this._mongooseOptions.sanitizeFilter;
  // }
 
  // AFTER (Patched): Resolves from connection config, connection options, global, or query
  opts.sanitizeFilter = model.db.config?.sanitizeFilter ??
    model.db.options?.sanitizeFilter ??
    model.base.options.sanitizeFilter ??
    this._mongooseOptions.sanitizeFilter;
 
  try {
    return cast(model.schema, obj, opts, this);
  } catch (err) {
    // ...
  }
};

In lib/cast.js, the patch prevents Mongoose from implicitly converting an array value into an $in operator when targeting a scalar schema path if options.sanitizeFilter is truthy. Furthermore, in the 6.x branch (commit b8970c25998c23fbccd17f76c0398b902ff4911d), the internal castQuery(query) helper in lib/query.js was updated to call query._castConditions() instead of directly invoking query.cast(query.model), ensuring that condition sanitization executes prior to schema casting across all legacy v6 execution paths.

// File: lib/cast.js
// BEFORE (Vulnerable): Implicitly cast array to $in regardless of sanitizeFilter
// } else if (Array.isArray(val) && ['Buffer', 'Array'].indexOf(schematype.instance) === -1) {
 
// AFTER (Patched): Disables implicit array-to-$in casting when sanitizeFilter is enabled
} else if (Array.isArray(val) && ['Buffer', 'Array'].indexOf(schematype.instance) === -1 && !options.sanitizeFilter) {
  const casted = [];
  const valuesArray = val;
  // ...

The fix completely resolves the disconnect between Connection.config and query casting, including for child connections derived via conn.useDb(), which inherit the parent connection's config object. However, developers should remain aware that sanitizeFilter only sanitizes query filter conditions; it does not sanitize aggregation pipelines (Model.aggregate()) or raw commands passed directly to the underlying MongoDB driver.

Exploiting CVE-2026-125119 requires an application endpoint that accepts structured user input—such as a JSON request body or URL query parameters parsed by qs—and passes properties from that input into a Mongoose query filter on a connection configured with { sanitizeFilter: true }. No authentication or special privileges are required if the vulnerable query resides on a public route such as a login, password reset, or search endpoint.

Consider an Express.js authentication endpoint where the developer configures sanitizeFilter: true inside mongoose.connect() and passes req.body.username and req.body.password directly to User.findOne():

const express = require('express');
const mongoose = require('mongoose');
 
const app = express();
app.use(express.json());
 
mongoose.connect('mongodb://127.0.0.1:27017/app', {
  sanitizeFilter: true
});
 
const User = mongoose.model('User', new mongoose.Schema({
  username: String,
  password: String
}));
 
app.post('/api/login', async (req, res) => {
  const user = await User.findOne({
    username: req.body.username,
    password: req.body.password
  });
  if (!user) return res.status(401).json({ error: 'Unauthorized' });
  return res.json({ authenticatedAs: user.username });
});

To bypass authentication, an attacker sends an HTTP POST request with Content-Type: application/json containing a nested MongoDB operator object ({"$ne": null}) in the password field, or an array of guessed values (["admin", "123456"]) to trigger implicit $in casting:

POST /api/login HTTP/1.1
Host: example.com
Content-Type: application/json
 
{
  "username": "admin",
  "password": {
    "$ne": null
  }
}

On unpatched Mongoose versions, User.findOne() ignores the connection's sanitizeFilter setting and sends { username: "admin", password: { $ne: null } } directly to MongoDB. MongoDB matches the admin user document because its password field is not null, logging the attacker in without knowing the password. On patched versions, sanitizeFilter rewrites the filter to { username: "admin", password: { $eq: { $ne: null } } }, which immediately fails schema casting for the String path and throws a CastError.

The security impact of CVE-2026-125119 is rated High with a CVSS v3.1 base score of 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N). The vulnerability is remotely exploitable over the network (AV:N) with low attack complexity (AC:L), requiring neither privileges (PR:N) nor user interaction (UI:N).

The failure to enforce sanitizeFilter affects the entire suite of Mongoose query operations that process filter conditions. As verified by the regression test suites introduced in the patch commits, the affected operations include:

• Read Operations: find(), findOne(), count(), countDocuments(), distinct(), and find().cursor()
• Update Operations: updateOne(), updateMany(), replaceOne(), findOneAndUpdate(), and findOneAndReplace()
• Delete Operations: deleteOne(), deleteMany(), findOneAndDelete(), and findOneAndRemove()
• Expression Operators: Queries containing $expr operators, which are supposed to be rejected with an error ($expr is not allowed with sanitizeFilter) when sanitizeFilter is active

In read contexts, attackers can bypass login gates or perform boolean-based and regular-expression-based ($regex) data extraction to enumerate sensitive fields such as password hashes, API keys, or reset tokens. While the baseline CVSS vector reflects Confidentiality Impact as High (C:H) and Integrity Impact as None (I:N), applications that pass user-controlled filter keys into write or delete methods (updateOne, deleteMany, findOneAndDelete) also face unauthorized data modification or destruction, as injected { "$ne": null } selectors can cause single-record updates or deletions to match unintended records.

To remediate CVE-2026-125119, upgrade Mongoose to the patched release corresponding to your active major version branch:

• Mongoose 9.x: Upgrade to 9.11.4 or later
• Mongoose 8.x: Upgrade to 8.24.7 or later
• Mongoose 7.x: Upgrade to 7.8.13 or later
• Mongoose 6.x: Upgrade to 6.13.12 or later

> [!NOTE] > Applications that configure sanitizeFilter globally via mongoose.set('sanitizeFilter', true) or explicitly on individual queries via .sanitizeFilter(true) are not affected by this vulnerability, as those code paths read from model.base.options and query._mongooseOptions respectively.

If an immediate library upgrade is not feasible, apply one or more of the following workarounds:

1. Enable sanitizeFilter Globally: Set mongoose.set('sanitizeFilter', true) at application startup. This populates mongoose.base.options.sanitizeFilter, which is properly evaluated by all affected versions.
2. Enforce Strict Input Schema Validation: Validate all incoming HTTP request bodies and query parameters at the controller or routing layer using a schema validation library (such as Zod, Joi, or Ajv). Ensure that fields expected to be strings, numbers, or booleans are strictly validated as scalar primitives before being passed to Mongoose methods.
3. Explicitly Cast or Wrap Inputs: Alternatively, wrap untrusted filter values in explicit $eq predicates (e.g., User.findOne({ username: { $eq: req.body.username } })) or cast them to primitives (String(req.body.username)) prior to constructing query objects.