CVE-2026-84367: 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.
Other sources
joi is a schema description language and data validator for JavaScript. From 16.0.0 until 17.13.5 and 18.2.4, joi's lib/types/keys.js internals.rename() implementation used by object().rename() permits a schema that renames keys with a regular-expression source and a Joi.expression() or Joi.x() target that interpolates the pattern's own match data, combined with { multiple: true }, to derive a target from an attacker-controlled input key. An attacker can send x-proto with an object value, causing the target to render as proto and set the prototype of the object returned by validate() instead of creating an own key. The global Object.prototype is not modified, so the effect is confined to the object returned by that validation call. Static-string targets and schemas using the default { multiple: false } are not affected. This issue is fixed in versions 17.13.5 and 18.2.4.
— NVD
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
joito a version that resolves this vulnerability.Fixed in 17.13.5 - Upgrade
Upgrade
joito a version that resolves this vulnerability.Fixed in 18.2.4 - Configuration
Update the schema to drop `{ multiple: true }` from `.rename(...)` so the rename stops before the assignment.
Joi schema (object().rename with template target) rename() options = { multiple: true } removed - Configuration
Keep `{ multiple: true }` but change the capture pattern to prevent `__proto__` from being produced by the template, e.g. `.rename(/^x-(?!__proto__$)(.+)$/, Joi.x('{#1}'), { multiple: true })`.
Joi schema (object().rename with template target) rename() regular-expression source template = Use negative lookahead to block __proto__ capture - Configuration
Replace the template rename target (e.g., `Joi.x('{#1}')`/`Joi.expression()`) with a static string target.
Joi schema (object().rename with template target) rename() target = Static string target
Event History
Frequently Asked Questions
Which schemas are affected in practice?
A schema is affected only when object().rename() uses a regular-expression source, a Joi.expression() or Joi.x() target that interpolates match data, and { multiple: true }. Static-string targets and the default { multiple: false } setting are not affected.
What input is needed to trigger the issue?
An attacker must be able to supply an object key that is processed by the vulnerable rename rule. For example, an input key of x-__proto__ with an object value can render the rename target as __proto__.
What is the impact of a successful exploit?
The prototype of the object returned by validate() can be set instead of creating an own property. Object.prototype globally is not modified, so the effect is limited to that validation result.
Which versions contain fixes?
The issue is fixed in joi versions 17.13.5 and 18.2.4. Affected versions begin at 16.0.0 and extend until those fixed releases.