GHSA-q89c-q3h5-w34g: i18next-http-backend has Path Traversal & URL Injection via Unsanitised lng/ns

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(resolvedLoadPath, { lng: languages.join('+'), ns: namespaces.join('+') })
• create — lib/index.js:123 (pre-patch): interpolate(addPath, { lng, ns: namespace })

The helper interpolate (lib/utils.js) previously returned the raw value with no encoding. In contrast, addQueryString already correctly uses encodeURIComponent for each query-string param — only the URL-path substitution was unprotected.