Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "3.7",
  "pubDate": "2026-09-01T21:18:47.887Z",
  "pubdate": "2026-09-01T21:18:47.887Z",
  "executiveSummary": "The Joi schema validation library contains a prototype pollution vulnerability residing within its configuration processing logic.\nThis vulnerability is categorized as Prototype Pollution, where an attacker can modify the base Object.prototype, potentially affecting all objects within the application's runtime environment.\nAffected packages include 'joi' (versions 16.0.0 through 17.13.5 and 18.0.0 through 18.2.4) and '@hapi/joi' (through 17.1.1).\nThe flaw stems from the insecure handling of user-supplied language keys during schema construction, specifically in functions that define custom messages or preferences.\nSuccessful exploitation requires that the application architecture allows untrusted user input to be passed directly into Joi's configuration methods, such as 'messages()', 'message()', 'prefs()', 'Joi.extend()', or 'rule()'.\nIf triggered, this vulnerability can lead to logic bypasses, denial of service, or potentially remote code execution, depending on the consuming application's reliance on inherited object properties.\nBecause '@hapi/joi' is no longer maintained, users are advised to migrate to the 'joi' package and apply the identified security patches.",
  "technicalDetails": "The vulnerability is located in 'lib/messages.js' within the 'exports.compile()' and 'exports.merge()' functions. These functions are responsible for processing schema-level configuration, specifically the mapping of custom language keys to error messages.\nThe root cause is the failure to sanitize or validate object keys during the recursive merge process. When an attacker provides a crafted object containing the key '__proto__' or 'constructor', the library inadvertently traverses and assigns values to the global Object prototype or the Object constructor's static properties.\nExploitation occurs when an application utilizes untrusted input to construct or modify a Joi schema dynamically. For example, if an API accepts a JSON payload that is passed directly into a 'Joi.extend()' call or a 'messages()' configuration block, the attacker can supply keys named '__proto__'.\nStep-by-step attack flow: 1. The attacker identifies an application endpoint that takes user input and passes it to a Joi configuration method (e.g., 'schema.messages(userInput)'). 2. The attacker submits a payload where one of the keys is '__proto__'. 3. 'lib/messages.js' executes an internal 'merge' operation on the provided input. 4. The merge logic recursively iterates through the attacker-supplied object. 5. Upon encountering the '__proto__' key, the assignment operation modifies the global Object.prototype, injecting arbitrary properties into every object initialized within the JavaScript runtime.\nThe post-exploitation impact is significant: because many JavaScript applications rely on checking for the presence of properties (e.g., 'if (obj.property)') or relying on default object behavior, polluting the prototype allows an attacker to alter the control flow of the application. An attacker can force the application to take incorrect execution branches, override security-sensitive configuration properties, or crash the application by interfering with standard object methods.\nThis vulnerability is not reachable via standard data validation workflows, as the flaw specifically targets the schema-definition phase rather than the data-validation phase. Consequently, applications that define static, hardcoded schemas are not at risk. Exposure is strictly limited to applications that treat Joi schema construction as a dynamic, user-controllable process."
}