CVE-2026-84367 in joi
Summary
by MITRE • 09/01/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/01/2026
The vulnerability identified involves a prototype pollution flaw within the Joi library, specifically affecting versions from 16.0.0 through 17.13.5 and 18.2.4. Joi is widely used in JavaScript ecosystems as a schema description language and data validator for validating objects against defined rules. The core of this vulnerability lies in the internal implementation of the rename functionality, specifically within the lib/types/keys.js file where the internals.rename() method operates. This function is invoked when an object().rename() rule is applied to a validation schema, allowing developers to map one key name to another during data processing.
The technical flaw arises from how Joi handles dynamic renaming using regular expressions combined with expression interpolation features such as Joi.expression() or Joi.x(). When a schema defines a rename operation where the source key matches via a regular expression and the target is constructed by interpolating match data, an attacker can manipulate this process if the multiple option is set to true. Under these specific conditions, the library fails to adequately sanitize or validate the resulting property name before assigning it on the object being validated. This lack of strict validation allows for the injection of special JavaScript prototype properties into the target object.
An attacker can exploit this by supplying an input key named x-_proto_. When processed through a vulnerable schema configuration, the internal logic interprets the suffix _proto_ as a directive to modify the object's prototype chain rather than creating a standard own property on the object instance. Consequently, properties set via this mechanism are attached directly to Object.prototype or influence the prototype of the returned validation result. This behavior constitutes a form of Prototype Pollution, where an attacker can inject properties into JavaScript objects that affect all subsequent instances created from those prototypes, potentially leading to denial of service through infinite loops in property enumeration or security bypasses if sensitive methods like toString are overwritten.
The operational impact is significant but somewhat constrained by the scope of execution. Because the global Object.prototype itself remains unmodified at a persistent level across the entire application runtime, the damage is largely confined to the specific object returned by that single validation call and any other objects created from it during that context. However, in applications where validated data structures are reused or passed between functions without deep cloning, this pollution can propagate further, leading to unpredictable behavior, crashes, or unauthorized access patterns depending on how downstream code interacts with the polluted prototype chain.
This vulnerability is categorized under CWE-1325, which covers Sensitive Prototype Pollution, and aligns with MITRE ATT&CK techniques related to Defense Evasion via process injection or script modification in client-side contexts. It highlights the risks associated with dynamic property name generation from untrusted input without rigorous sanitization of reserved JavaScript identifiers such as _proto_, constructor, and prototype.
To mitigate this risk, organizations using affected versions of Joi must upgrade immediately to version 17.13.5 or later for the v17 branch, or version 18.2.4 and above for the v18 branch. These releases include patches that prevent the interpolation logic from resolving to prototype-affecting property names when multiple renaming is enabled. Additionally, developers should review schemas using dynamic key renaming with regular expressions and consider implementing additional validation layers to ensure that target keys do not resolve to reserved JavaScript object properties. Avoiding the use of Joi.expression() or Joi.x() for constructing rename targets based on user-controlled input patterns is a recommended defensive coding practice until all systems are updated.