CVE-2026-90771 in Joi
Summary
by MITRE • 09/13/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/13/2026
The JavaScript validation library Joi, prior to versions 17.13.8 and 18.2.9, contains a critical Prototype Pollution vulnerability within its message compilation function. This flaw arises from the way the library processes custom error messages provided by developers or end-users during schema definition. Specifically, the internal logic fails to adequately sanitize input keys before merging them into an object that serves as part of the validation context. When an attacker supplies _proto_ as a key in these custom message configurations, the JavaScript engine interprets this not merely as a property name but as a directive to modify the prototype chain of the target object. This behavior is intrinsic to how standard Object.assign or similar merging utilities operate when handling untrusted input without explicit protection against prototype manipulation.
The technical mechanism behind this vulnerability relies on the fact that in many JavaScript environments, setting _proto_ directly on an object updates its internal [[Prototype]] property rather than creating a new enumerable property named proto. In the context of Joi's error message compilation, if user-controlled data is used to construct or extend configuration objects without filtering out dangerous keys like _proto_, constructor, or prototype, it allows for indirect injection into global JavaScript prototypes. By polluting Object.prototype through this vector, an attacker can inject properties that are inherited by all subsequent object creations in the application runtime. This effectively compromises the integrity of the entire execution environment because every new object instantiated after the pollution will inherit these malicious attributes unless explicitly overridden or if the prototype is reset.
The operational impact of such a vulnerability extends beyond simple data corruption, potentially leading to severe security consequences including Denial of Service and Remote Code Execution scenarios depending on how downstream code utilizes affected objects. If application logic relies on standard Object.prototype methods like hasOwnProperty, toString, or valueOf, these can be overridden by the polluted prototype, causing unexpected behavior such as infinite loops during iteration or crashes when expected properties are missing. Furthermore, if the compromised object is used in security-sensitive checks, such as authentication tokens or permission flags stored within objects that inherit from the polluted prototype, an attacker might bypass access controls entirely. The persistence of this pollution means that a single instance of exploitation can affect all subsequent requests processed by the same Node.js process until it restarts, amplifying the blast radius significantly in long-running server applications.
Mitigation strategies primarily involve upgrading to patched versions of Joi where 17.13.8 and 18.2.9 or later are required. These updates include safeguards that prevent _proto_ from being used as a key for prototype modification, typically by freezing prototypes or using Object.create(null) for intermediate objects during message compilation. For applications unable to upgrade immediately, developers should implement strict input validation on any user-supplied data passed into Joi schemas, ensuring that keys containing special characters like underscores followed by proto are rejected before reaching the library's internal functions. Additionally, employing security middleware or linters that detect prototype pollution patterns can help identify risky coding practices early in the development lifecycle. It is also advisable to review custom message configurations for any dynamic key generation based on user input and apply sanitization routines such as filtering out dangerous keys explicitly using Object.keys() checks before passing them to Joi's validation methods.