Joi EUVD-2026-117085

Exploitation requires an application to pass attacker-controlled data directly into Joi's custom message configuration - specifically any().messages(), message(), prefs({ messages }), Joi.extend({ messages }), or rule({ message }) - where the untrusted object contains a __proto__ (or constructor) key treated as a language name. This is explicitly NOT reachable from data that Joi validates; custom messages are schema-construction configuration normally written by developers, so the vulnerability only manifests in the non-default, insecure pattern of feeding untrusted input straight into schema construction. The primary limiting factor is this unusual configuration flow, reflected in AC:H and AT:P; impact is confined to altered or broken validation error rendering and corruption of application logic that gates on mere property presence. Vendor workaround: do not pass untrusted input into those APIs, or strip any __proto__/constructor property before doing so; upgrading is the complete fix.

This is a medium-severity, low-real-world-priority issue despite the network attack vector. The CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:N/UI:N) scores 6.3, but the high attack complexity (AC:H), the present attack requirement (AT:P), and the impact profile (VI:L only; VC:N, VA:N) all signal a narrow, low-impact flaw rather than a broadly dangerous one. The GHSA is explicit that this is NOT reachable from data that Joi validates - custom messages are schema-construction configuration normally authored by the application developer, so PR:N reflects the lack of auth on the hypothetical exposed endpoint, not that typical deployments are remotely exploitable. The vuln.today decision label is 'this_month' (not act_now/emergency), and the vulnerability is NOT listed in CISA KEV, consistent with the low urgency. No EPSS score was provided in the input, so probabilistic exploitation likelihood cannot be factored in - this is a data gap. No standalone weaponized exploit is cited, though the vendor patch ships a test that demonstrates the technique. The dominant limiting factor is the unusual and insecure coding pattern required (feeding untrusted input directly into schema construction), which makes widespread exploitation unlikely and points to this being a defense-in-depth hardening fix rather than an active threat.

An application forwards attacker-controlled JSON directly into Joi schema construction - for example building a schema with user-supplied custom error messages via any().messages() or prefs({ messages }). The attacker submits a payload containing a __proto__ language key (e.g. JSON.parse('{"__proto__":{"number.min":"pwned"}}')), which replaces the compiled messages object's prototype so lookups resolve through inheritance, corrupting validation error rendering and any downstream logic that gates on property presence. No public weaponized exploit is cited, but the vendor's patch includes a working test case demonstrating the exact trigger.