CVE-2026-84368
LowCVSS 3.7Exploitation Probability (EPSS)
Low risk17th percentile - higher than 17% of all known CVEs
Summary
The joi library (and @hapi/joi) has a prototype pollution vulnerability in lib/messages.js. The exports.compile() and exports.merge() functions reuse inherited objects for attacker-controlled language keys, allowing properties to be written to Object.prototype.
Risk Assessment
Applications that rely on the presence of inherited properties may take wrong branches for every inspected object, potentially leading to malfunction or security logic bypass.
Recommendation
Update the joi library to version 17.13.6 or 18.2.5. For @hapi/joi, no fix is available, so consider migrating to joi.
Other vulnerabilities in joi
See all- CVE-2026-92599High
joi (npm package `joi`, hapi.js) versions >=17.2.0 <17.13.7 and >=18.0.0 <18.2.6 are vulnerable to regular expression denial of service in the `Joi.string().isoDate()` validation rule. One of the regular expressions the rule applies to the input is unanchored, so a valid ISO date followed by a long run of fractional-second digits causes the regex engine to restart its search from every position in the string, yielding time proportional to the square of the input length (about 1.4 s for 64 KB of digits and about 22 s for 256 KB). A remote attacker who can supply a string to an isoDate validation can stall the application with a single request. Fixed in 17.13.7 and 18.2.6; as a workaround, cap the length of the string before it reaches joi.
- CVE-2026-90771Low
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.
- CVE-2026-84367Low
In the joi library, there is a vulnerability in the internals.rename() implementation used by object().rename(). It allows creating a schema that, using a regular expression and a Joi.expression() or Joi.x() target with match data interpolation, can set the prototype of the object returned by validate() to __proto__ instead of creating an own key.
- CVE-2026-48038Medium
A vulnerability in the joi library (versions before 17.13.4 and 18.2.1) allows a DoS attack by sending deeply nested JSON or objects with recursive link() schemas. Calling validate() without try/catch in a request handler can cause an unhandled RangeError and potentially crash the process.
Original NVD description (English source)
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.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS