{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "i18next-http-middleware"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.9.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42353"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-29T22:26:36Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nVersions of `i18next-http-middleware` prior to 3.9.3 pass the user-controlled `lng` and `ns` values from `getResourcesHandler` directly into `i18next.services.backendConnector.load(languages, namespaces, \u2026)` without any sanitisation. Depending on which backend is configured, the unvalidated path segments enable one of two attacks:\n\n- **Filesystem path traversal** when the middleware is paired with `i18next-fs-backend` (or any backend that interpolates `lng` / `ns` into a filesystem path).\n- **Server-Side Request Forgery (SSRF)** when the middleware is paired with `i18next-http-backend` (or any backend that interpolates into an HTTP URL).\n\nExample request:\n\n```\nGET /locales/resources.json?lng=../../etc/passwd\u0026ns=root\n```\n\nwith `i18next-fs-backend` reads the attacker-chosen file from disk; with `i18next-http-backend` reshapes the outgoing URL to target an internal service.\n\n### Impact\n\n- **Arbitrary file read** via `fs`-style backends \u2014 any file the Node process can read becomes reachable (source, configuration, `.ssh` keys, `.env`, Docker secrets, etc.).\n- **SSRF** via `http`-style backends \u2014 requests to internal IPs / hostnames not normally reachable from the internet; combined with cloud metadata endpoints this can escalate to credential theft.\n- **Unbounded growth of `i18next.options.ns`** \u2014 a now-incidental amplification: the pre-patch `getResourcesHandler` pushed every unique `ns` value into the shared `i18next.options.ns` singleton array without validation or bounds, enabling memory exhaustion from repeated unique payloads.\n\nThe severity is bounded by the backend in place, but the middleware itself exposed the unsanitised path; this is the \"weakest link\" layer.\n\n### Affected versions\n\n`\u003c 3.9.3`.\n\n### Patch\n\nFixed in **3.9.3**. The patch introduces `utils.isSafeIdentifier` and applies it in `getResourcesHandler` before `lng` and `ns` reach the backend connector:\n\n```js\nlanguages  = languages.filter(utils.isSafeIdentifier)\nnamespaces = namespaces.filter(utils.isSafeIdentifier)\n```\n\n`isSafeIdentifier` uses a denylist approach \u2014 it still accepts any legitimate i18next language-code shape ([i18next FAQ](https://www.i18next.com/how-to/faq#how-should-the-language-codes-be-formatted)) \u2014 rejecting:\n\n- `..` sequences (relative path traversal)\n- path separators (`/`, `\\`)\n- control characters (C0/C1)\n- prototype keys (`__proto__` / `constructor` / `prototype`)\n- empty strings and values longer than 128 characters\n\nUnsafe values are dropped; only safe values reach the backend. The fix is a defence-in-depth layer on top of any sanitisation the backend itself may apply.\n\n### Workarounds\n\nNo workaround short of upgrading. Front-proxying the middleware with a WAF rule that rejects requests containing `..`, `/`, `\\`, or URL-structure characters in `lng` / `ns` is a partial mitigation. Upgrading the configured backend (`i18next-fs-backend` \u2265 2.6.4, `i18next-http-backend` \u2265 3.0.5) also closes the same attack at the next layer.\n\n### Related advisories fixed in the same release\n\n- [GHSA-5fgg-jcpf-8jjw](https://github.com/i18next/i18next-http-middleware/security/advisories/GHSA-5fgg-jcpf-8jjw) \u2014 prototype pollution via `setPath` and `missingKeyHandler`. Independently fixable, filed separately per CNA rules.\n- [GHSA-c3h8-g69v-pjrg](https://github.com/i18next/i18next-http-middleware/security/advisories/GHSA-c3h8-g69v-pjrg) \u2014 HTTP response splitting + XSS-filter bypass (CVE-2026-41683).\n\n### Credits\n\nDiscovered via an internal security audit of the i18next ecosystem.\n\n### Resources\n\n- [CWE-22: Path Traversal](https://cwe.mitre.org/data/definitions/22.html)\n- [CWE-918: Server-Side Request Forgery (SSRF)](https://cwe.mitre.org/data/definitions/918.html) (specific sub-case when paired with an HTTP backend)\n- [i18next FAQ: language code formatting](https://www.i18next.com/how-to/faq#how-should-the-language-codes-be-formatted)",
  "id": "GHSA-jfgf-83c5-2c4m",
  "modified": "2026-04-29T22:26:36Z",
  "published": "2026-04-29T22:26:36Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/i18next/i18next-http-middleware/security/advisories/GHSA-jfgf-83c5-2c4m"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/i18next/i18next-http-middleware"
    },
    {
      "type": "WEB",
      "url": "https://www.i18next.com/how-to/faq#how-should-the-language-codes-be-formatted"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "i18next-http-middleware has path traversal / SSRF via user-controlled language and namespace parameters"
}