🚨 [security] [backend] Update mongoose 6.0.8 → 9.9.0 (major)

[depfu]

---

🚨 Your current dependencies have known security vulnerabilities 🚨

This dependency update fixes known security vulnerabilities. Please see the details below and assess their impact carefully. We recommend to merge and deploy this as soon as possible!

---

Here is everything you need to know about this upgrade. Please take a good look at what changed and the test results before merging this pull request.

What changed?

✳️ mongoose (6.0.8 → 9.9.0) · Repo · Changelog

Security Advisories 🚨

🚨 Mongoose: Prototype pollution in mongoose update casting via __proto__-prefixed dotted path (Schema._getSchema/path getter)

Impact

What kind of vulnerability is it? Who is impacted?

Prototype pollution in update casting: passing a user-controlled update to a Mongoose update, like MyModel.updateOne(filter, req.body), can cause Mongoose to set $fullPath and $parentSchemaDocArray on Object.prototype.

Example:

const mongoose = require('mongoose');
console.log('before:', Object.prototype.$fullPath);            // undefined
const User = mongoose.model('User', new mongoose.Schema({ name: String }));

const malicious = JSON.parse('{"$set": {"proto.x": "anything"}}');   // attacker-controlled update
const q = User.updateOne({}, {});

try { q._castUpdate(malicious); } catch (e) { /* throws AFTER the pollution side-effect */ }
console.log('after :', Object.prototype.$fullPath);            // "proto"

console.log('enumerable:', Object.prototype.propertyIsEnumerable('$fullPath'));  // true

console.log('fresh {}:', ({}).$fullPath);                      // "proto"

Patches

Has the problem been patched? What versions should users upgrade to?

9.7.2, 8.24.1. 7.8.10, 6.13.10

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

Check user-controlled updates for own __proto__ properties before passing to Mongoose

References

Are there any links users can visit to find out more?

🚨 Mongoose: Prototype pollution in mongoose update casting via __proto__-prefixed dotted path (Schema._getSchema/path getter)

Impact

What kind of vulnerability is it? Who is impacted?

Prototype pollution in update casting: passing a user-controlled update to a Mongoose update, like MyModel.updateOne(filter, req.body), can cause Mongoose to set $fullPath and $parentSchemaDocArray on Object.prototype.

Example:

const mongoose = require('mongoose');
console.log('before:', Object.prototype.$fullPath);            // undefined
const User = mongoose.model('User', new mongoose.Schema({ name: String }));

const malicious = JSON.parse('{"$set": {"proto.x": "anything"}}');   // attacker-controlled update
const q = User.updateOne({}, {});

try { q._castUpdate(malicious); } catch (e) { /* throws AFTER the pollution side-effect */ }
console.log('after :', Object.prototype.$fullPath);            // "proto"

console.log('enumerable:', Object.prototype.propertyIsEnumerable('$fullPath'));  // true

console.log('fresh {}:', ({}).$fullPath);                      // "proto"

Patches

Has the problem been patched? What versions should users upgrade to?

9.7.2, 8.24.1. 7.8.10, 6.13.10

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

Check user-controlled updates for own __proto__ properties before passing to Mongoose

References

Are there any links users can visit to find out more?

🚨 Mongoose: Prototype pollution in mongoose update casting via __proto__-prefixed dotted path (Schema._getSchema/path getter)

Impact

What kind of vulnerability is it? Who is impacted?

Prototype pollution in update casting: passing a user-controlled update to a Mongoose update, like MyModel.updateOne(filter, req.body), can cause Mongoose to set $fullPath and $parentSchemaDocArray on Object.prototype.

Example:

const mongoose = require('mongoose');
console.log('before:', Object.prototype.$fullPath);            // undefined
const User = mongoose.model('User', new mongoose.Schema({ name: String }));

const malicious = JSON.parse('{"$set": {"proto.x": "anything"}}');   // attacker-controlled update
const q = User.updateOne({}, {});

try { q._castUpdate(malicious); } catch (e) { /* throws AFTER the pollution side-effect */ }
console.log('after :', Object.prototype.$fullPath);            // "proto"

console.log('enumerable:', Object.prototype.propertyIsEnumerable('$fullPath'));  // true

console.log('fresh {}:', ({}).$fullPath);                      // "proto"

Patches

Has the problem been patched? What versions should users upgrade to?

9.7.2, 8.24.1. 7.8.10, 6.13.10

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

Check user-controlled updates for own __proto__ properties before passing to Mongoose

References

Are there any links users can visit to find out more?

🚨 Mongoose: Prototype pollution in mongoose update casting via __proto__-prefixed dotted path (Schema._getSchema/path getter)

Impact

What kind of vulnerability is it? Who is impacted?

Prototype pollution in update casting: passing a user-controlled update to a Mongoose update, like MyModel.updateOne(filter, req.body), can cause Mongoose to set $fullPath and $parentSchemaDocArray on Object.prototype.

Example:

const mongoose = require('mongoose');
console.log('before:', Object.prototype.$fullPath);            // undefined
const User = mongoose.model('User', new mongoose.Schema({ name: String }));

const malicious = JSON.parse('{"$set": {"proto.x": "anything"}}');   // attacker-controlled update
const q = User.updateOne({}, {});

try { q._castUpdate(malicious); } catch (e) { /* throws AFTER the pollution side-effect */ }
console.log('after :', Object.prototype.$fullPath);            // "proto"

console.log('enumerable:', Object.prototype.propertyIsEnumerable('$fullPath'));  // true

console.log('fresh {}:', ({}).$fullPath);                      // "proto"

Patches

Has the problem been patched? What versions should users upgrade to?

9.7.2, 8.24.1. 7.8.10, 6.13.10

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

Check user-controlled updates for own __proto__ properties before passing to Mongoose

References

Are there any links users can visit to find out more?

🚨 Mongoose's Improper Sanitization of $nor in sanitizeFilter May Allow NoSQL Injection

Impact

This vulnerability allows bypassing Mongoose’s sanitizeFilter query sanitization mechanism via the $nor operator.

When sanitizeFilter is enabled, Mongoose wraps query operators in $eq to neutralize them. However, prior to the fix, $nor was not included in the set of logical operators that are recursively sanitized. Because $nor accepts an array (like $and and $or), and arrays do not trigger hasDollarKeys(), malicious operators such as $ne, $gt, or $regex could be injected inside a $nor clause without being sanitized.

This may lead to:

• Authentication bypass
• Unauthorized data access
• Data exfiltration

Affected users:

Applications that:

• Explicitly enable sanitizeFilter
• Pass unsanitized user-controlled input directly into query methods (e.g., Model.findOne(req.body)) and rely on sanitizeFilter to strip out query selectors

Applications that validate input schemas, whitelist fields, or avoid passing raw request bodies into queries are not affected. For example, Model.findOne({ user: req.body.user, pwd: req.body.pwd }) is not affected.

Patches

Patches have been released for all supported Mongoose release lines:

• ^6.13.9
• ^7.8.9
• ^8.22.1
• ^9.1.6

Workarounds

Delete $nor keys, use an additional schema validation library, or write middleware to strip out $nor from query filters.

Resources

sanitizeFilter documentation: https://mongoosejs.com/docs/api/mongoose.html#Mongoose.prototype.sanitizeFilter()

Original blog post on sanitizeFilter: https://thecodebarbarian.com/whats-new-in-mongoose-6-sanitizefilter.html

🚨 Mongoose's Improper Sanitization of $nor in sanitizeFilter May Allow NoSQL Injection

Impact

This vulnerability allows bypassing Mongoose’s sanitizeFilter query sanitization mechanism via the $nor operator.

When sanitizeFilter is enabled, Mongoose wraps query operators in $eq to neutralize them. However, prior to the fix, $nor was not included in the set of logical operators that are recursively sanitized. Because $nor accepts an array (like $and and $or), and arrays do not trigger hasDollarKeys(), malicious operators such as $ne, $gt, or $regex could be injected inside a $nor clause without being sanitized.

This may lead to:

• Authentication bypass
• Unauthorized data access
• Data exfiltration

Affected users:

Applications that:

• Explicitly enable sanitizeFilter
• Pass unsanitized user-controlled input directly into query methods (e.g., Model.findOne(req.body)) and rely on sanitizeFilter to strip out query selectors

Applications that validate input schemas, whitelist fields, or avoid passing raw request bodies into queries are not affected. For example, Model.findOne({ user: req.body.user, pwd: req.body.pwd }) is not affected.

Patches

Patches have been released for all supported Mongoose release lines:

• ^6.13.9
• ^7.8.9
• ^8.22.1
• ^9.1.6

Workarounds

Delete $nor keys, use an additional schema validation library, or write middleware to strip out $nor from query filters.

Resources

sanitizeFilter documentation: https://mongoosejs.com/docs/api/mongoose.html#Mongoose.prototype.sanitizeFilter()

Original blog post on sanitizeFilter: https://thecodebarbarian.com/whats-new-in-mongoose-6-sanitizefilter.html

🚨 Mongoose's Improper Sanitization of $nor in sanitizeFilter May Allow NoSQL Injection

Impact

This vulnerability allows bypassing Mongoose’s sanitizeFilter query sanitization mechanism via the $nor operator.

When sanitizeFilter is enabled, Mongoose wraps query operators in $eq to neutralize them. However, prior to the fix, $nor was not included in the set of logical operators that are recursively sanitized. Because $nor accepts an array (like $and and $or), and arrays do not trigger hasDollarKeys(), malicious operators such as $ne, $gt, or $regex could be injected inside a $nor clause without being sanitized.

This may lead to:

• Authentication bypass
• Unauthorized data access
• Data exfiltration

Affected users:

Applications that:

• Explicitly enable sanitizeFilter
• Pass unsanitized user-controlled input directly into query methods (e.g., Model.findOne(req.body)) and rely on sanitizeFilter to strip out query selectors

Applications that validate input schemas, whitelist fields, or avoid passing raw request bodies into queries are not affected. For example, Model.findOne({ user: req.body.user, pwd: req.body.pwd }) is not affected.

Patches

Patches have been released for all supported Mongoose release lines:

• ^6.13.9
• ^7.8.9
• ^8.22.1
• ^9.1.6

Workarounds

Delete $nor keys, use an additional schema validation library, or write middleware to strip out $nor from query filters.

Resources

sanitizeFilter documentation: https://mongoosejs.com/docs/api/mongoose.html#Mongoose.prototype.sanitizeFilter()

Original blog post on sanitizeFilter: https://thecodebarbarian.com/whats-new-in-mongoose-6-sanitizefilter.html

🚨 Mongoose's Improper Sanitization of $nor in sanitizeFilter May Allow NoSQL Injection

Impact

This vulnerability allows bypassing Mongoose’s sanitizeFilter query sanitization mechanism via the $nor operator.

When sanitizeFilter is enabled, Mongoose wraps query operators in $eq to neutralize them. However, prior to the fix, $nor was not included in the set of logical operators that are recursively sanitized. Because $nor accepts an array (like $and and $or), and arrays do not trigger hasDollarKeys(), malicious operators such as $ne, $gt, or $regex could be injected inside a $nor clause without being sanitized.

This may lead to:

• Authentication bypass
• Unauthorized data access
• Data exfiltration

Affected users:

Applications that:

• Explicitly enable sanitizeFilter
• Pass unsanitized user-controlled input directly into query methods (e.g., Model.findOne(req.body)) and rely on sanitizeFilter to strip out query selectors

Applications that validate input schemas, whitelist fields, or avoid passing raw request bodies into queries are not affected. For example, Model.findOne({ user: req.body.user, pwd: req.body.pwd }) is not affected.

Patches

Patches have been released for all supported Mongoose release lines:

• ^6.13.9
• ^7.8.9
• ^8.22.1
• ^9.1.6

Workarounds

Delete $nor keys, use an additional schema validation library, or write middleware to strip out $nor from query filters.

Resources

sanitizeFilter documentation: https://mongoosejs.com/docs/api/mongoose.html#Mongoose.prototype.sanitizeFilter()

Original blog post on sanitizeFilter: https://thecodebarbarian.com/whats-new-in-mongoose-6-sanitizefilter.html

🚨 Mongoose search injection vulnerability

Mongoose versions prior to 8.9.5, 7.8.4, and 6.13.6 are vulnerable to improper use of the $where operator. This vulnerability arises from the ability of the $where clause to execute arbitrary JavaScript code in MongoDB queries, potentially leading to code injection attacks and unauthorized access or manipulation of database data.

NOTE: this issue exists because of an incomplete fix for CVE-2024-53900.

🚨 Mongoose search injection vulnerability

Mongoose versions prior to 8.9.5, 7.8.4, and 6.13.6 are vulnerable to improper use of the $where operator. This vulnerability arises from the ability of the $where clause to execute arbitrary JavaScript code in MongoDB queries, potentially leading to code injection attacks and unauthorized access or manipulation of database data.

NOTE: this issue exists because of an incomplete fix for CVE-2024-53900.

🚨 Mongoose search injection vulnerability

Mongoose versions prior to 8.8.3, 7.8.3, 6.13.5, and 5.13.23 are vulnerable to improper use of the $where operator. This vulnerability arises from the ability of the $where clause to execute arbitrary JavaScript code in MongoDB queries, potentially leading to code injection attacks and unauthorized access or manipulation of database data.

🚨 Mongoose search injection vulnerability

Mongoose versions prior to 8.8.3, 7.8.3, 6.13.5, and 5.13.23 are vulnerable to improper use of the $where operator. This vulnerability arises from the ability of the $where clause to execute arbitrary JavaScript code in MongoDB queries, potentially leading to code injection attacks and unauthorized access or manipulation of database data.

🚨 Mongoose search injection vulnerability

Mongoose versions prior to 8.8.3, 7.8.3, 6.13.5, and 5.13.23 are vulnerable to improper use of the $where operator. This vulnerability arises from the ability of the $where clause to execute arbitrary JavaScript code in MongoDB queries, potentially leading to code injection attacks and unauthorized access or manipulation of database data.

🚨 Mongoose Prototype Pollution vulnerability

Prototype Pollution in GitHub repository automattic/mongoose prior to 7.3.3, 6.11.3, and 5.13.20.

🚨 Mongoose Prototype Pollution vulnerability

Prototype Pollution in GitHub repository automattic/mongoose prior to 7.3.3, 6.11.3, and 5.13.20.

🚨 Mongoose Vulnerable to Prototype Pollution in Schema Object

Description

Mongoose is a MongoDB object modeling tool designed to work in an asynchronous environment.

Affected versions of this package are vulnerable to Prototype Pollution. The Schema.path() function is vulnerable to prototype pollution when setting the schema object. This vulnerability allows modification of the Object prototype and could be manipulated into a Denial of Service (DoS) attack.

Proof of Concept

// poc.js
const mongoose = require('mongoose');
const schema = new mongoose.Schema();
malicious_payload = 'proto.toString'
schema.path(malicious_payload, [String])
x = {}

console.log(x.toString()) // crashed (Denial of service (DoS) attack)

Impact

This vulnerability can be manipulated to exploit other types of attacks, such as Denial of service (DoS), Remote Code Execution, or Property Injection.

🚨 automattic/mongoose vulnerable to Prototype pollution via Schema.path

Mongoose is a MongoDB object modeling tool designed to work in an asynchronous environment. Affected versions of this package are vulnerable to Prototype Pollution. The Schema.path() function is vulnerable to prototype pollution when setting the schema object. This vulnerability allows modification of the Object prototype and could be manipulated into a Denial of Service (DoS) attack.

Release Notes

Too many releases to show here. View the full release notes.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ @​types/webidl-conversions (indirect, 6.1.1 → 7.0.3) · Repo

Sorry, we couldn't find anything useful about this release.

↗️ @​types/whatwg-url (indirect, 8.2.1 → 13.0.0) · Repo

Sorry, we couldn't find anything useful about this release.

↗️ bson (indirect, 4.5.2 → 7.3.1) · Repo · Changelog

Release Notes

Too many releases to show here. View the full release notes.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ kareem (indirect, 2.3.2 → 3.3.0) · Repo · Changelog

Release Notes

3.3.0 (from changelog)

More info than we can show here.

3.2.0 (from changelog)

More info than we can show here.

3.1.0 (from changelog)

More info than we can show here.

3.0.0 (from changelog)

More info than we can show here.

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ mongodb (indirect, 4.1.1 → 7.5.0) · Repo · Changelog

Security Advisories 🚨

🚨 MongoDB Driver may publish events containing authentication-related data

Some MongoDB Drivers may erroneously publish events containing authentication-related data to a command listener configured by an application. The published events may contain security-sensitive data when specific authentication-related commands are executed.

Without due care, an application may inadvertently expose this sensitive information, e.g., by writing it to a log file. This issue only arises if an application enables the command listener feature (this is not enabled by default).

This issue affects the MongoDB C Driver 1.0.0 prior to 1.17.7, MongoDB PHP Driver 1.0.0 prior to 1.9.2, MongoDB Swift Driver 1.0.0 prior to 1.1.1, MongoDB Node.js Driver 3.6 prior to 3.6.10, MongoDB Node.js Driver 4.0 prior to 4.17.0 and MongoDB Node.js Driver 5.0 prior to 5.8.0. This issue also affects users of the MongoDB C++ Driver dependent on the C driver 1.0.0 prior to 1.17.7 (C++ driver prior to 3.7.0).

🚨 MongoDB Driver may publish events containing authentication-related data

Some MongoDB Drivers may erroneously publish events containing authentication-related data to a command listener configured by an application. The published events may contain security-sensitive data when specific authentication-related commands are executed.

Without due care, an application may inadvertently expose this sensitive information, e.g., by writing it to a log file. This issue only arises if an application enables the command listener feature (this is not enabled by default).

This issue affects the MongoDB C Driver 1.0.0 prior to 1.17.7, MongoDB PHP Driver 1.0.0 prior to 1.9.2, MongoDB Swift Driver 1.0.0 prior to 1.1.1, MongoDB Node.js Driver 3.6 prior to 3.6.10, MongoDB Node.js Driver 4.0 prior to 4.17.0 and MongoDB Node.js Driver 5.0 prior to 5.8.0. This issue also affects users of the MongoDB C++ Driver dependent on the C driver 1.0.0 prior to 1.17.7 (C++ driver prior to 3.7.0).

Release Notes

Too many releases to show here. View the full release notes.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ mongodb-connection-string-url (indirect, 2.1.0 → 7.0.2) · Repo · Changelog

Release Notes

7.0.2

More info than we can show here.

7.0.1

More info than we can show here.

7.0.0

More info than we can show here.

3.0.2

More info than we can show here.

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ mpath (indirect, 0.8.4 → 0.9.0) · Repo · Changelog

Release Notes

0.9.0 (from changelog)

More info than we can show here.

Does any of this look wrong? Please let us know.

↗️ mquery (indirect, 4.0.0 → 6.0.0) · Repo · Changelog

Release Notes

6.0.0 (from changelog)

More info than we can show here.

5.0.0 (from changelog)

More info than we can show here.

4.0.3 (from changelog)

More info than we can show here.

4.0.2 (from changelog)

More info than we can show here.

4.0.1 (from changelog)

More info than we can show here.

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ punycode (indirect, 2.1.1 → 2.3.1) · Repo

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ sift (indirect, 13.5.2 → 17.1.3) · Repo · Changelog

Release Notes

16.0.0 (from changelog)

More info than we can show here.

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ tr46 (indirect, 2.1.0 → 5.1.1) · Repo

Release Notes

5.1.1

More info than we can show here.

5.1.0

More info than we can show here.

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ webidl-conversions (indirect, 6.1.0 → 7.0.0) · Repo

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ whatwg-url (indirect, 9.1.0 → 14.2.0) · Repo

Release Notes

14.2.0

More info than we can show here.

14.1.1

More info than we can show here.

14.1.0

More info than we can show here.

14.0.0

More info than we can show here.

13.0.0

More info than we can show here.

12.0.1

More info than we can show here.

12.0.0

More info than we can show here.

11.0.0

More info than we can show here.

10.0.0

More info than we can show here.

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

🆕 @​mongodb-js/saslprep (added, 1.4.13)

🆕 @​standard-schema/spec (added, 1.1.0)

🗑️ @​types/node (removed)

🗑️ base64-js (removed)

🗑️ buffer (removed)

🗑️ denque (removed)

🗑️ ieee754 (removed)

🗑️ regexp-clone (removed)

🗑️ saslprep (removed)

🗑️ sliced (removed)

---

👉 No CI detected

You don't seem to have any Continuous Integration service set up!

Without a service that will test the Depfu branches and pull requests, we can't inform you if incoming updates actually work with your app. We think that this degrades the service we're trying to provide down to a point where it is more or less meaningless.

This is fine if you just want to give Depfu a quick try. If you want to really let Depfu help you keep your app up-to-date, we recommend setting up a CI system:

* [Circle CI](https://circleci.com), [Semaphore ](https://semaphoreci.com) and [Github Actions](https://docs.github.com/actions) are all excellent options. * If you use something like Jenkins, make sure that you're using the Github integration correctly so that it reports status data back to Github. * If you have already set up a CI for this repository, you might need to check your configuration. Make sure it will run on all new branches. If you don’t want it to run on every branch, you can whitelist branches starting with `depfu/`.

---

Depfu will automatically keep this PR conflict-free, as long as you don't add any commits to this branch yourself. You can also trigger a rebase manually by commenting with @depfu rebase.

All Depfu comment commands

@​depfu rebase

Rebases against your default branch and redoes this update

@​depfu recreate

Recreates this PR, overwriting any edits that you've made to it

@​depfu merge

Merges this PR once your tests are passing and conflicts are resolved

@​depfu cancel merge

Cancels automatic merging of this PR

@​depfu close

Closes this PR and deletes the branch

@​depfu reopen

Restores the branch and reopens this PR (if it's closed)

@​depfu pause

Ignores all future updates for this dependency and closes this PR

@​depfu pause [minor|major]

Ignores all future minor/major updates for this dependency and closes this PR

@​depfu resume

Future versions of this dependency will create PRs again (leaves this PR as is)

[depfu]

Closed in favor of #534.