[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 update. Please take a good look at what changed and the test results before merging this pull request.

What changed?

✳️ joi (17.6.0 → 17.13.7) · Repo · Changelog

Security Advisories 🚨

🚨 joi: object().rename() with a template target can set the validated object's prototype

Impact

Applications are affected only if a schema renames keys with a regular-expression source and a Joi.expression() / Joi.x() target that interpolates the pattern's own match data, combined with { multiple: true }, for example .rename(/^x-(.+)$/, Joi.x('{#1}'), { multiple: true }). Because the target is rendered from the matched input key, an attacker who controls input keys can send x-__proto__ with an object value and make the rename target render as __proto__, which sets the prototype of the object joi returns instead of creating a key on it. The global Object.prototype is not modified, so the effect is confined to the object returned by that one validate() call.

Schemas using a static string rename target are not affected, and neither are schemas left on the default { multiple: false }.

Patches

Versions 17.13.5 and 18.2.4 have been released to address the issue.

Workarounds

1. Replace the template rename target with a static string target.
2. Keep the template but make the capture unable to produce __proto__, using a negative lookahead: .rename(/^x-(?!__proto__$)(.+)$/, Joi.x('{#1}'), { multiple: true })
3. Drop { multiple: true } from the rename, which stops the rename before the assignment.

🚨 joi: Prototype pollution via a `__proto__` language key in custom messages

Impact

An application that passes attacker-controlled data into joi's custom message configuration (messages(), message(), prefs({ messages }), Joi.extend({ messages }) or rule({ message })) lets the attacker write properties onto Object.prototype, where every object in the process then inherits them. A key named __proto__ was treated as a language name, and the code reused the object it found at that key, which resolves to the prototype rather than to a new own property; a key named constructor did the same to the Object function's statics. A consuming application that gates on the mere presence of a property (if (user.isAdmin)) can be made to take the wrong branch for every object it inspects.

This is not reachable from data that joi validates. Custom messages are schema-construction configuration, normally written by the application developer. Exploitation therefore requires an application that feeds untrusted input straight into schema construction.

Patches

Upgrade to version 18.2.5 or 17.13.6.

Workarounds

Do not pass untrusted input into messages(), message(), prefs({ messages }), Joi.extend({ messages }) or rule({ message }). Or validate that they don't contain any __proto__ or constructor property.

🚨 joi has an uncaught RangeError on deeply nested input through recursive `link()` schemas

Impact

Denial of service via untrapped exception in services validating user-supplied JSON / object input with recursive link schemas.

The blast radius depends on how the application invokes joi:

• Highest impact: validate() called without try/catch in a request handler would cause an unhandled exception, potentially crashing the process.
• Lower impact: validateAsync() or validate() inside a try/catch, the validation fails, but the error type is RangeError rather than a structured ValidationError, complicating error handling.

Patches

Upgrade to version >= 18.2.1.

Workarounds

Try/catch the validation to avoid uncaught exceptions.

References

• Pull request: #3113

Commits

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

↗️ @​sideway/address (indirect, 4.1.4 → 4.1.5) · Repo

Commits

See the full diff on Github. The new version differs by 2 commits:

• 4.1.5
• chore: update tlds (#47)

↗️ @​sideway/formula (indirect, 3.0.0 → 3.0.1) · Repo

Security Advisories 🚨

🚨 @sideway/formula contains Regular Expression Denial of Service (ReDoS) Vulnerability

Impact

User-provided strings to formula's parser might lead to polynomial execution time.

Patches

Users should upgrade to 3.0.1+.

Workarounds

None.

Commits

See the full diff on Github. The new version differs by 4 commits:

• 3.0.1
• chore: better number regex
• Cleanup
• Move to Sideway

---

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 #35.