i18next-http-middleware Prototype Pollution Bypass via missingKeyHandler Fix

Vulnerability Overview i18next-http-middleware missingKeyHandler fails to reject keys containing prototype pollution names Description: In version 3.9.6 of , the blocks literal request keys such as , , and , but does not block dotted variants like . Downstream backends (such as ≤ 2.6.5) pass these keys as unquoted calls against . Impact: Applications that expose to unauthorized users and utilize ≤ 2.6.5 are directly vulnerable to remote prototype pollution. Other backends that split missing key strings in the same manner may also be affected. Within the host application, polluted key attributes can lead to crashes, corrupted translation behavior, configuration poisoning, or bypass of attribute-based security checks. Affected Versions Affected versions: < 3.9.7 Fixed versions: 3.9.7 Remediation Patch: In 3.9.7, a new helper function was introduced for . The configured is respected (the default disables segment splitting, meaning only literal key whitelisting applies). Legitimate dotted keys (e.g., ) remain unaffected. Root Cause Fix: Released in 2.6.6; see the comparison guidance. Workarounds If an immediate upgrade is not possible: Do not expose to unauthorized users (place it behind authentication, or remove the route entirely). Before configuring , add a request body filter to reject any top-level keys containing , , or . Disable missing key persistence when accepting writes ( ). References Original report by @codeswhite. Comparison guidance: - GHSA-2933-q333-gqk3 Previous security releases: GHSA-5fpg-ppgf-6jqr and GHSA-c3h8-gfhy-gpg (in version 3.9.3). POC Code No specific POC code is provided.

Goal Reached Thanks to every supporter — we hit 100%!

i18next-http-middleware Prototype Pollution Bypass via missingKeyHandler Fix

More from this source