GHSA-gg4h-3hg2-grpc

Dashboard / Vulnerabilities / GHSA-gg4h-3hg2-grpc

GHSA-gg4h-3hg2-grpc

Summary: joi: object().rename() with a template target can set the validated object's prototype

Details: ### Impact Applications are affected only if a schema renames keys with a regular-expression source and a `Joi.expression()` / `Joi.x()` target that interpolates the pattern's own match data, combined with `{ multiple: true }`, for example `.rename(/^x-(.+)$/, Joi.x('{#1}'), { multiple: true })`. Because the target is rendered from the matched input key, an attacker who controls input keys can send `x-__proto__` with an object value and make the rename target render as `__proto__`, which sets the prototype of the object joi returns instead of creating a key on it. The global `Object.prototype` is not modified, so the effect is confined to the object returned by that one `validate()` call. Schemas using a static string rename target are not affected, and neither are schemas left on the default `{ multiple: false }`. ### Patches Versions 17.13.5 and 18.2.4 have been released to address the issue. ### Workarounds 1. Replace the template rename target with a static string target. 2. Keep the template but make the capture unable to produce `__proto__`, using a negative lookahead: `.rename(/^x-(?!__proto__$)(.+)$/, Joi.x('{#1}'), { multiple: true })` 3. Drop { multiple: true } from the rename, which stops the rename before the assignment.

References: https://github.com/hapijs/joi/security/advisories/GHSA-gg4h-3hg2-grpc, https://nvd.nist.gov/vuln/detail/CVE-2026-84367, https://github.com/hapijs/joi/pull/3134, https://github.com/hapijs/joi/pull/3135, https://github.com/hapijs/joi/commit/162f367aa178d2e1ebec8dc1164e5fe16536ddf6, https://github.com/hapijs/joi/commit/172ececa192feda532b743d77bc9d3e523d19b01, https://github.com/hapijs/joi, https://github.com/hapijs/joi/releases/tag/v17.13.5, https://github.com/hapijs/joi/releases/tag/v18.2.4