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 before versions 17.13.8 and 18.2.9 contains a prototype pollution vulnerability in the messages compilation function that accepts proto as an error code. Attackers can supply proto keys in custom messages to replace the returned object's prototype, breaking downstream code relying on Object.prototype methods.