i18next-http-backend

### Summary The URL-segment check added for GHSA-q89c-q3h5-w34g blocks `?`, `#`, `%`, `:`, `/` and `@` in `lng`, but not `&` or `=`, and the checked value is inserted into the URL without encoding. The README documents a multiload loadPath of the form `/locales/resources.json?lng=de+en&ns=ns1+ns2`. With a template like that, an attacker who controls the language value can add or override query parameters on the request the backend sends. By default the language comes from `?lng=`, a cookie or `Accept-Language`. This is the "query-string injection" impact described in GHSA-q89c; only the `?` f

CVE: CVE-2026-118258

## 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}}

CVE: CVE-2026-115730

## Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-9jhj-wvmw-cfx5. This link is maintained to preserve external references. ## Original Descriptioni18next-http-backend 4.0.2 contains an incomplete fix in interpolateUrl() that allows attackers to redirect translation requests by supplying an ns value starting with a slash. Attackers controlling the namespace value can form a protocol-relative URL in loadPath or addPath templates to load attacker-hosted translations, enabling UI content injection and cross-site scripting.

There is an SSRF vulnerability when using `i18next-http-backend`. A colon in an attacker-controlled language value can make a custom path template request an unintended origin. This is reachable under the following conditions: Attacker controls i18next language or namespace input that is interpolated into loadPath. ## Proof of Concept ```js // SSRF through a colon-only URL scheme in i18next-http-backend interpolation. const http = require("node:http"); const Backend = require("i18next-http-backend"); function read(backend, lng, ns) { return new Promise((resolve) => { backend.read(lng

CVE: CVE-2026-105800

### Summary Versions of `i18next-http-backend` prior to 3.0.5 interpolate the `lng` and `ns` values directly into the configured `loadPath` / `addPath` URL template without any encoding, validation, or path sanitisation. When an application exposes the language-code selection to user-controlled input (the default — `i18next-browser-languagedetector` reads `?lng=` query params, cookies, `localStorage`, and request headers), an attacker can inject characters that change the structure of the outgoing request URL. Affected call sites: - `_readAny` — `lib/index.js:64`: `interpolate(resolvedLoadP

CVE: CVE-2026-41691