🚨 [security] Update mongoose 5.7.9 → 9.8.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 (5.7.9 → 9.8.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 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 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.

🚨 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.

🚨 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.

✳️ chart.js (2.9.1 → 2.9.4) · Repo

Security Advisories 🚨

🚨 Prototype pollution in chart.js

This affects the package chart.js before 2.9.4. The options parameter is not properly sanitized when it is processed. When the options are processed, the existing options (or the defaults options) are deeply merged with provided options. However, during this operation, the keys of the object being set are not checked, leading to a prototype pollution.

Release Notes

2.9.4

More info than we can show here.

2.9.3

More info than we can show here.

2.9.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.

↗️ kareem (indirect, 2.3.1 → 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.

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

Security Advisories 🚨

🚨 Type confusion in mpath

This affects the package mpath before 0.8.4. A type confusion vulnerability can lead to a bypass of CVE-2018-16490. In particular, the condition ignoreProperties.indexOf(parts[i]) !== -1 returns -1 if parts[i] is ['__proto__']. This is because the method that has been called if the input is an array is Array.prototype.indexOf() and not String.prototype.indexOf(). They behave differently depending on the type of the input.

Release Notes

0.9.0 (from changelog)

More info than we can show here.

0.8.4 (from changelog)

More info than we can show here.

0.8.3 (from changelog)

More info than we can show here.

0.8.2 (from changelog)

More info than we can show here.

0.8.1 (from changelog)

More info than we can show here.

0.8.0 (from changelog)

More info than we can show here.

0.7.0 (from changelog)

More info than we can show here.

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

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

Security Advisories 🚨

🚨 Code Injection in mquery

lib/utils.js in mquery before 3.2.3 allows a pollution attack because a special property (e.g., proto) can be copied during a merge or clone operation.

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.

3.2.5 (from changelog)

More info than we can show here.

3.2.4 (from changelog)

More info than we can show here.

3.2.3 (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.

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

Release Notes

16.0.0 (from changelog)

More info than we can show here.

12.0.0 (from changelog)

More info than we can show here.

11.0.0 (from changelog)

More info than we can show here.

10.0.0 (from changelog)

More info than we can show here.

9.0.0 (from changelog)

More info than we can show here.

8.5.1 (from changelog)

More info than we can show here.

8.5.0 (from changelog)

More info than we can show here.

8.4.0 (from changelog)

More info than we can show here.

8.3.2 (from changelog)

More info than we can show here.

8.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-js/saslprep (added, 1.4.13)

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

🆕 @​types/webidl-conversions (added, 7.0.3)

🆕 @​types/whatwg-url (added, 13.0.0)

🆕 mongodb-connection-string-url (added, 7.0.2)

🆕 tr46 (added, 5.1.1)

🆕 webidl-conversions (added, 7.0.0)

🆕 whatwg-url (added, 14.2.0)

🗑️ emoji-regex (removed)

🗑️ mongoose-legacy-pluralize (removed)

🗑️ regexp-clone (removed)

🗑️ sliced (removed)

---

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)