CVE-2026-48714: i18next-http-middleware missingKeyHandler does not reject keys whose segments contain prototype-polluting names
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
- 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).
Other sources
i18next-http-middleware is a middleware to be used with Node.js web frameworks like express or Fastify and also for Deno. In versions prior to 3.9.7, the 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. This issue has been fixed in version 3.9.7. If developers cannot upgrade immediately, they should do the following: 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 their configured keySeparator, and disable missing-key persistence (saveMissing: false) when accepting writes from untrusted input.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/i18next-http-middlewareto a version that resolves this vulnerability.Fixed in 3.9.7 - Upgrade
Upgrade
i18next-http-middlewareto a version that resolves this vulnerability.Fixed in 3.9.7 - Upgrade
Upgrade
i18next-fs-backendto a version that resolves this vulnerability.Fixed in 2.6.6 - Configuration
When accepting writes from untrusted input, disable missing-key persistence by setting saveMissing: false.
i18next-http-middleware missingKeyHandler saveMissing = false - Configuration
Do not expose missingKeyHandler to untrusted users; mount it behind authentication or remove the route.
missingKeyHandler exposure authentication = required - Configuration
Add a request-body filter ahead of the handler that rejects any top-level key containing __proto__, constructor, or prototype after splitting on the configured keySeparator.
Request-body filter (for missingKeyHandler) denylist = __proto__,constructor,prototype
Event History
Frequently Asked Questions
What is the severity of CVE-2026-48714?
The severity of CVE-2026-48714 is rated as critical with a score of 9.1.
How do I fix CVE-2026-48714?
To fix CVE-2026-48714, upgrade i18next-http-middleware to version 3.9.7 or later.
What applications are affected by CVE-2026-48714?
CVE-2026-48714 affects i18next-http-middleware versions prior to 3.9.7, which is used with Node.js frameworks.
What vulnerabilities does CVE-2026-48714 introduce?
CVE-2026-48714 allows the acceptance of prototype-polluting keys in the missingKeyHandler function, potentially leading to security issues.
When was CVE-2026-48714 published?
CVE-2026-48714 was published on June 15, 2026.