UBUNTU-CVE-2026-63402: Medium severity ubuntu/node-i18next vulnerability
i18next is an internationalization framework for JavaScript. Prior to version 26.3.4, deepExtend in src/utils.js checks property existence with the in operator and recurses into inherited built-ins reached through Object.prototype. An application must explicitly pass attacker-controlled resource data to addResourceBundle(lng, ns, data, deep, overwrite) with both deep: true and overwrite: true. Source keys such as hasOwnProperty, toString and valueOf can then select shared inherited built-in function objects, and a nested value can overwrite a property of those objects process-wide. For example, making Object.prototype.hasOwnProperty.call non-callable causes subsequent uses, including i18next internals, to throw TypeError, resulting in unrecoverable denial of service and limited integrity impact. The proto/constructor guard does not prevent this mechanism because the corruption target is an inherited built-in function rather than the prototype object itself. Default calls without deep merging or with overwrite falsy are unaffected, and no standard i18next backend or integration uses the vulnerable configuration. This issue is distinct from the setPath/key-walking prototype-pollution flaws in i18next-fs-backend (CVE-2026-48713) and i18next-http-middleware (CVE-2026-48714). This issue is fixed in version 26.3.4.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
i18nextto a version that resolves this vulnerability.Fixed in 26.3.4
Event History
Frequently Asked Questions
Which deployments are actually exposed?
Only applications that explicitly pass attacker-controlled resource data to addResourceBundle with both deep set to true and overwrite set to true are exposed. Default calls that do not deep merge, or use a falsy overwrite value, are unaffected; standard i18next backends and integrations do not use the vulnerable configuration.
What must an attacker be able to do?
An attacker needs to control source resource data supplied to the affected addResourceBundle call. They can use keys such as hasOwnProperty, toString, or valueOf with nested values to modify properties on inherited built-in function objects.
What happens if exploitation succeeds?
The attacker can corrupt shared built-in function objects process-wide. For example, replacing Object.prototype.hasOwnProperty.call with a non-callable value can cause subsequent operations, including i18next internals, to raise TypeError and produce an unrecoverable denial of service; the stated integrity impact is limited.
What can be done before patching?
Do not pass attacker-controlled resource data to addResourceBundle using deep: true together with overwrite: true. Avoiding either deep merging or a truthy overwrite value prevents the described vulnerable path.