Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "3.7",
  "pubDate": "2026-09-01T21:18:47.737Z",
  "pubdate": "2026-09-01T21:18:47.737Z",
  "executiveSummary": "This vulnerability is a prototype pollution flaw affecting the joi library, specifically within the object().rename() functionality.\nThe issue arises from unsafe processing of user-controlled input keys when using dynamic targets in conjunction with regular expressions and the { multiple: true } option.\nBy manipulating the interpolation of match data, an attacker can coerce the validator to set the __proto__ property of the object returned by the validate() function.\nThe scope of the pollution is constrained to the result object of the specific validation call, preventing global contamination of the Object.prototype.\nAffected products include joi versions 16.0.0 through 17.13.4 and 18.0.0 through 18.2.3.\nExploitation requires the application to permit external inputs to dictate key renaming targets within a joi schema, potentially leading to logic bypass or unexpected object behavior within the application context.",
  "technicalDetails": "The vulnerability resides within lib/types/keys.js in the internals.rename() implementation. The core issue is an improper handling of target key resolution when object().rename() is utilized with dynamic, attacker-influenced input.\nWhen a schema defines a rename operation using a regular expression source and a Joi.expression() or Joi.x() target, the validator attempts to interpolate match data from the regular expression into the target key name.\nAn attacker can provide a specially crafted input key, such as x-__proto__, which interacts with the renaming logic. When the { multiple: true } configuration option is enabled, the logic fails to sanitize the resultant target key.\nThe interpolation process transforms the input into the string '__proto__'. Because the validator subsequently assigns this result as a key on the object being processed, the JavaScript engine interprets the key as a prototype assignment rather than a standard own-property addition.\nThe attack flow is as follows: 1) The attacker identifies a schema that uses object().rename() with regex-based keys and dynamic targets. 2) The attacker crafts an input object containing a key designed to resolve to '__proto__'. 3) The joi validation engine processes the rename operation, rendering the target key as '__proto__'. 4) The library assigns the provided value to the internal prototype slot of the result object. 5) The application receives the result object, which now possesses a polluted prototype, potentially altering its behavior or access to inherited properties.\nThis behavior specifically impacts the output of validate(), effectively injecting arbitrary properties into the instance's prototype chain. While the vulnerability does not achieve global persistence—as Object.prototype remains untouched—it allows for local state manipulation within the validated object instance, which can be leveraged to bypass input constraints or subvert application logic dependent on that object's structure.\nStatic-string targets and configurations omitting { multiple: true } remain unaffected by this vulnerability due to the stricter, non-dynamic nature of the key resolution process in those configurations."
}