Impact
i18next-http-middleware ≤ 3.9.6's missingKeyHandler blocked the literal request-body keys __proto__, constructor, and prototype (added in 3.9.3, see GHSA-5fgg-jcpf-8jjw), but did not reject dotted variants such as "__proto__.polluted". Downstream backends that split the missing-key string on a configured keySeparator (notably i18next-fs-backend ≤ 2.6.5) hand these keys to an unguarded setPath() walker that writes to Object.prototype.
Applications that expose missingKeyHandler to untrusted input AND use i18next-fs-backend ≤ 2.6.5 are directly exploitable for remote prototype pollution. Other downstream backends that split the missing-key string the same way may be similarly affected.
Depending on the host application, polluted prototype properties may cause crashes, corrupted translation behaviour, configuration poisoning, or bypasses of property-based security checks.
Patches
Fixed in i18next-http-middleware 3.9.7. A new utils.hasUnsafeKeySegment(key, keySeparator) helper is now used by missingKeyHandler; the configured i18next.options.keySeparator is honoured (default .; false disables segment splitting and only the literal-key denylist applies). Legitimate dotted keys (e.g. "header.title") are unaffected.
The root-cause fix has been shipped in i18next-fs-backend 2.6.6 — see the companion advisory.
Workarounds
If users cannot upgrade immediately:
- Do not expose
missingKeyHandler to untrusted users (mount it behind authentication, or remove the route).
- Add a request-body filter ahead of the handler that rejects any top-level key containing
__proto__, constructor, or prototype after splitting on a configured keySeparator.
- Disable missing-key persistence (
saveMissing: false) when accepting writes from untrusted input.
Resources
References
codeswhite Finder
Impact
i18next-http-middleware≤ 3.9.6'smissingKeyHandlerblocked the literal request-body keys__proto__,constructor, andprototype(added in 3.9.3, see GHSA-5fgg-jcpf-8jjw), but did not reject dotted variants such as"__proto__.polluted". Downstream backends that split the missing-key string on a configuredkeySeparator(notablyi18next-fs-backend≤ 2.6.5) hand these keys to an unguardedsetPath()walker that writes toObject.prototype.Applications that expose
missingKeyHandlerto untrusted input AND usei18next-fs-backend≤ 2.6.5 are directly exploitable for remote prototype pollution. Other downstream backends that split the missing-key string the same way may be similarly affected.Depending on the host application, polluted prototype properties may cause crashes, corrupted translation behaviour, configuration poisoning, or bypasses of property-based security checks.
Patches
Fixed in i18next-http-middleware 3.9.7. A new
utils.hasUnsafeKeySegment(key, keySeparator)helper is now used bymissingKeyHandler; the configuredi18next.options.keySeparatoris honoured (default.;falsedisables segment splitting and only the literal-key denylist applies). Legitimate dotted keys (e.g."header.title") are unaffected.The root-cause fix has been shipped in
i18next-fs-backend2.6.6 — see the companion advisory.Workarounds
If users cannot upgrade immediately:
missingKeyHandlerto untrusted users (mount it behind authentication, or remove the route).__proto__,constructor, orprototypeafter splitting on a configuredkeySeparator.saveMissing: false) when accepting writes from untrusted input.Resources
i18next-fs-backend: GHSA-2933-q333-qg83.i18next-http-middlewaresecurity release: GHSA-5fgg-jcpf-8jjw and GHSA-c3h8-g69v-pjrg (in 3.9.3).References