CVE-2026-48714
ADVISORY - githubSummary
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
missingKeyHandlerto 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, orprototypeafter splitting on a configuredkeySeparator. - 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-middlewaresecurity release: GHSA-5fgg-jcpf-8jjw and GHSA-c3h8-g69v-pjrg (in 3.9.3).
Common Weakness Enumeration (CWE)
Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
GitHub
3.9
CVSS SCORE
9.1critical| Package | Type | OS Name | OS Version | Affected Ranges | Fix Versions |
|---|---|---|---|---|---|
| i18next-http-middleware | npm | - | - | <3.9.7 | 3.9.7 |
CVSS:3 Severity and metrics
The CVSS metrics represent different qualitative aspects of a vulnerability that impact the overall score, as defined by the CVSS Specification.
The vulnerable component is bound to the network stack, but the attack is limited at the protocol level to a logically adjacent topology. This can mean an attack must be launched from the same shared physical (e.g., Bluetooth or IEEE 802.11) or logical (e.g., local IP subnet) network, or from within a secure or otherwise limited administrative domain (e.g., MPLS, secure VPN to an administrative network zone). One example of an Adjacent attack would be an ARP (IPv4) or neighbor discovery (IPv6) flood leading to a denial of service on the local LAN segment (e.g., CVE-2013-6014).
Specialized access conditions or extenuating circumstances do not exist. An attacker can expect repeatable success when attacking the vulnerable component.
The attacker is unauthorized prior to attack, and therefore does not require any access to settings or files of the vulnerable system to carry out an attack.
The vulnerable system can be exploited without interaction from any user.
An exploited vulnerability can only affect resources managed by the same security authority. In this case, the vulnerable component and the impacted component are either the same, or both are managed by the same security authority.
There is no loss of confidentiality.
There is a total loss of integrity, or a complete loss of protection. For example, the attacker is able to modify any or all files protected by the impacted component. Alternatively, only some files can be modified, but malicious modification would present a direct, serious consequence to the impacted component.
There is a total loss of availability, resulting in the attacker being able to fully deny access to resources in the impacted component; this loss is either sustained (while the attacker continues to deliver the attack) or persistent (the condition persists even after the attack has completed). Alternatively, the attacker has the ability to deny some availability, but the loss of availability presents a direct, serious consequence to the impacted component.
NIST
3.9