Is i18next-http-middleware safe?

GHSA-f49m-vf83-692w

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.

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.

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.

• Original report by @codeswhite.
• Companion advisory in i18next-fs-backend: GHSA-2933-q333-qg83.
• Previous i18next-http-middleware security release: GHSA-5fgg-jcpf-8jjw and GHSA-c3h8-g69v-pjrg (in 3.9.3).