GHSA-gg4h-3hg2-grpc: Low severity npm/joi vulnerability
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/joito a version that resolves this vulnerability.Fixed in 18.2.4 - Upgrade
Upgrade
npm/joito a version that resolves this vulnerability.Fixed in 17.13.5 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 17.13.5 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 18.2.4 - Configuration
Drop the `{ multiple: true }` option from the affected `.rename()` call so the rename stops before the assignment.
Joi schema .rename() multiple option in .rename(regexp, Joi.x/template, { multiple: true }) = Remove { multiple: true } (set multiple to false by omission) - Configuration
Keep the template but change the capture regex to prevent producing `__proto__`, e.g., use a negative lookahead: `.rename(/^x-(?!__proto__$)(.+)$/, Joi.x('{#1}'), { multiple: true })`.
Joi schema .rename() rename regex used with Joi.x('{#1}') = .rename(/^x-(?!__proto__$)(.+)$/, Joi.x('{#1}'), { multiple: true }) - Configuration
Replace the template rename target with a static string target; schemas with a static string rename target are not affected.
Joi schema .rename() rename target template = static string target (e.g., Joi.string literal / static string instead of Joi.x('{#1}'))
Event History
Frequently Asked Questions
Which Joi schemas are actually exposed to this issue?
Only schemas that use a regular-expression rename source, a Joi.expression() or Joi.x() rename target that interpolates the match data, and { multiple: true } are affected. Static rename targets and schemas using the default { multiple: false } are not affected.
What must an attacker control to trigger the behavior?
The attacker must be able to supply input keys to validation. A key such as x-__proto__ with an object value can cause a matching template target to render as __proto__.
What is the impact of successful exploitation?
The prototype of the object returned by the affected validate() call can be set instead of a normal key being created. Object.prototype is not modified, so the effect is confined to that individual returned object.
What can be done if upgrading is not immediately possible?
Replace the template rename target with a static string target, remove { multiple: true }, or prevent __proto__ from being captured with a negative lookahead such as /^x-(?!__proto__$)(.+)$/. The described patches are available in versions 17.13.5 and 18.2.4.