CVE-2026-122131 in Joi
Summary
by MITRE • 11/04/2026
Joi 17.13.6 before 17.13.9 and 18.2.5 before 18.3.1 contains a prototype pollution vulnerability in lib/messages.js compile() and merge() that fails to reject a __proto__ language key. Attackers supplying untrusted message configuration via any().messages(), prefs, validate options or Joi.extend can replace the compiled messages prototype, altering or breaking validation error rendering and dependent logic.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/04/2026
The vulnerability identified in Joi versions prior to 17.13.9 and 18.3.1 represents a critical Prototype Pollution flaw located within the lib/messages.js module, specifically affecting the compile() and merge() functions. This security issue stems from an insufficient validation of input keys during the message configuration process. When attackers supply untrusted data through any().messages(), prefs, validate options, or Joi.extend methods, they can inject specific language keys that include _proto_. Because these functions fail to reject such keys, the JavaScript engine interprets them as attempts to modify the Object prototype chain rather than standard dictionary entries for error messages. This behavior allows malicious actors to pollute the global object prototype by adding properties like toString or constructor directly onto it, which affects all subsequent objects created in the application runtime environment.
The operational impact of this vulnerability is significant and multifaceted. By successfully injecting a _proto_ key into the message configuration, an attacker can alter or completely break the rendering of validation errors within the Joi library itself. This disruption can lead to unexpected behavior in applications that rely on structured error reporting for user feedback or logging mechanisms. More critically, prototype pollution serves as a potent vector for broader application compromise. Once the Object.prototype is polluted with malicious properties, these changes persist across all objects instantiated after the attack. Attackers can leverage this state to execute arbitrary code, bypass security checks, or cause denial of service conditions by corrupting core JavaScript methods used throughout the application logic. The persistence of the pollution means that even if the initial request is handled correctly, the compromised prototype affects subsequent requests until the server process restarts or the pollution is explicitly cleaned up.
From a classification perspective, this vulnerability aligns with CWE-1325, which covers Prototype Pollution via unsafe merging operations, and CWE-915, regarding Improperly Controlled Modification of Dynamically-Determined Object Attributes. In terms of offensive security frameworks, it maps to the ATT&CK technique T1484.002, known as Domain Policy Modification or more broadly under Defense Evasion techniques where attackers manipulate environment variables or object states to evade detection and maintain persistence within the application logic. The flaw highlights a common oversight in deep cloning or merging utilities that do not strictly enforce key sanitization against reserved JavaScript property names.
To mitigate this vulnerability, organizations must immediately upgrade Joi to version 17.13.9 or later for the v17 branch, or version 18.3.1 and above for the v18 branch. These releases include patches that explicitly reject _proto_ keys during message compilation and merging processes, thereby preventing prototype pollution at the source. For applications unable to upgrade immediately due to dependency constraints, implementing a custom validation layer before passing any configuration objects into Joi functions can provide temporary protection. This involves recursively sanitizing input data to remove or escape reserved property names such as _proto_, constructor, and prototype. Additionally, developers should review all instances where user-supplied data is passed directly into message configurations, prefs, or extension methods without prior validation. Adopting strict schema definitions that explicitly define allowed keys can further reduce the attack surface by ensuring only expected properties are processed during configuration merges.