Vulnerabilidades de Hapijs

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.

joi is a schema description language and data validator for JavaScript. From 16.0.0 until 17.13.6 and 18.2.5, the @hapi/joi package through 17.1.1 and the successor joi package contain prototype pollution in lib/messages.js, where exports.compile() and exports.merge() reuse inherited objects for attacker-controlled language keys supplied through messages(), message(), prefs({ messages }), Joi.extend({ messages }), or rule({ message }). A language key named __proto__ writes properties onto Object.prototype, and constructor writes to the Object function's static properties. A consuming application that gates on the presence of an inherited property can take the wrong branch for every inspected object. The flaw is not reachable from data that joi validates and requires an application to feed untrusted input directly into schema-construction configuration. This issue is fixed in joi versions 17.13.6 and 18.2.5; no fixed @hapi/joi version is available.

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.