i18next-http-backend has Path Traversal & URL Injection via Unsanitised lng/ns
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(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.
Impact
An attacker who can influence the resolved lng or ns value can alter the URL in several ways:
- Path traversal —
lng = '../../config'turns/locales/{{lng}}/{{ns}}.jsoninto/locales/../../config/translation.json. On a misconfigured web server, this can cause the request to target a different resource than intended; in SSR pipelines that usefile://or similar schemes forloadPath, it can read arbitrary files from the host filesystem. - Query-string injection —
lng = 'en?admin=true'turns/locales/{{lng}}/{{ns}}.jsoninto/locales/en?admin=true/translation.json. Some server frameworks parse the query portion with higher priority than the path and branch on attacker-controlled flags. - Fragment truncation —
lng = 'en#anything'silently discards the rest of the path in browser fetches (client cannot see the final URL). - URL-encoded bypasses —
lng = 'en%2F..', after server-side URL decoding, resolves toen/..— the attacker bypasses the absence of a literal/in their input.
The practical worst case is SSRF when loadPath is an internal or file-scheme URL, and path-based authorisation bypass against servers that segment access by URL prefix.
Also fixed in 3.0.5
- Per-instance
omitFetchOptions. A module-level boolean inlib/request.jswas flipped totruethe first time any backend instance hit a "not implemented" fetch error. Once flipped, all subsequent requests from all backend instances in the same module silently stripped every user-configured fetch option — including security-relevantcredentials,mode, andcache. One misbehaving instance (for example during SSR hydration or in React Native) permanently removed these protections process-wide. 3.0.5 scopes the flag to the backend'soptionsobject (options._omitFetchOptions) so one instance's fallback cannot pollute siblings. - Log forging via control characters in
lng/ns. Error callbacks embedded the rawlng/ns/URL in the message string. Crafted CR/LF values could inject fake log lines into file-backed log aggregators (CWE-117). 3.0.5 strips C0/C1 control chars before concatenation. - Basic-auth credentials leaked into error callbacks. If
loadPathcontained auser:password@hostauthority, the full URL (including the credentials) ended up in the error message strings returned to the caller. 3.0.5 redactsuser:password@before logging. - Prototype-pollution amplification via
for...in.addQueryStringand the XHRcustomHeadersloop usedfor...inwhich walks the prototype chain. PollutedObject.prototypeentries could leak into URL query parameters and request headers. 3.0.5 usesObject.keysand an explicit prototype-key guard.
Affected versions
All versions of i18next-http-backend prior to 3.0.5.
Patch
Fixed in 3.0.5. Summary of the hardening:
- New
utils.interpolateUrl(used by_readAnyandcreate) returnsnullif any substitution fails the URL-segment safety check (blocks..,/,\,?,#,%,@, whitespace, control chars, prototype keys, and values > 128 chars). Multi-language joins (en+de) are validated per-segment. The call sites now refuse to issue a request when the check fails and call back with a clear error. omitFetchOptionsis stored per-instance onoptions._omitFetchOptions.- Error-callback messages sanitise strings and redact URL credentials.
for...inover untrusted objects replaced withObject.keys+ prototype-key guard.
Workarounds
No workaround short of upgrading. If you cannot upgrade immediately, sanitise lng / ns yourself before they reach i18next (strip .., /, \, ?, #, %, whitespace, and control characters; cap the length).
Credits
Discovered via an internal security audit of the i18next ecosystem.
Betroffene Software
Klicken Sie auf eine Technologie, um alle zugehörigen Schwachstellen anzuzeigen.
| Plattform | Paket | Anfällige Versionen | Behoben in |
|---|---|---|---|
| npm-Paket | i18next-http-backend | < 3.0.5 | 3.0.5 |
Verweise
- CVSS-Vektor
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N- Schwäche (CWE)
CWE-22, CWE-74- Plattform
- npm
- Paket
i18next-http-backend- Veröffentlicht
- 22.04.2026
- Aktualisiert
- 11.10.2026 10:22
Quellen und Lizenzen
OSV / GitHub Advisory Database - GHSA-q89c-q3h5-w34g - CC BY 4.0
Schwachstellenhistorie: i18next-http-backend
Alle veröffentlichten Schwachstellen dieses Pakets (npm-Paket), neueste zuerst. Zeigt, ob es ein einmaliger Ausrutscher ist oder ein Paket, das man im Auge behalten muss.
- Einträge insgesamt
- 2
- Erste → letzte
- 04.2026 10.2026
- Ohne Fix
- 0
- In Angriffen ausgenutzt
- 0
Verteilung nach Schweregrad
- Mittel 1
- Niedrig 1
Veröffentlichungen pro Jahr
- 2026: 2
-
i18next-http-backend has Path Traversal & URL Injection via Unsanitised lng/ns dieser Eintrag
Erkennen Sie Schwachstellen in Ihrer Anwendung
Mit der DockRay-Integration und aktivierter Softwareinventarisierung prüft DockRay gemeldete Komponentenversionen auf bekannte Schwachstellen und benachrichtigt Sie über bestätigte Treffer. Die Abdeckung hängt von der unterstützten Technologie und den verfügbaren Meldungen ab.