CVE-2026-84368
LowCVSS 3.7Summary
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-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.