{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "i18next-http-middleware"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.9.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41683"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-113",
      "CWE-79"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-22T20:25:49Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nVersions of `i18next-http-middleware` prior to 3.9.3 wrote user-controlled language values into the `Content-Language` response header after passing them through `utils.escape()`, which is an HTML-entity encoder that does not strip carriage return, line feed, or other control characters. When the application used an older `i18next` (\u003c 19.5.0) that still exercised the backward-compatibility fallback at `LanguageDetector.js:100` or otherwise produced a raw detected value, CRLF sequences in the attacker-controlled `lng` parameter reached `res.setHeader(\u0027Content-Language\u0027, ...)` verbatim.\n\n### Impact\n\nTwo concrete outcomes depending on the Node.js version:\n\n- **Node.js \u003c 14.6.0 \u2014 HTTP response splitting.** An attacker crafting a request like `GET /?lng=en%0d%0aX-Injected%3A+malicious` could inject arbitrary additional HTTP response headers, enabling:\n  - Session fixation via an injected `Set-Cookie`\n  - Cache poisoning (injecting `Location`, `Content-Type`, etc.)\n  - Reflected XSS in controlled response bodies\n- **Node.js \u2265 14.6.0 \u2014 denial of service.** `res.setHeader()` throws `ERR_INVALID_CHAR` when the value contains CRLF. Because the middleware did not catch this error, it propagated as an unhandled exception, returning a 500 response to **all concurrent users sharing that process** (in worker-pool deployments this can knock out a full server instance).\n\nThe same header-setting code path fires inside the `languageChanged` event listener and again in the main middleware flow, so the flaw was triggered at least twice per affected request.\n\n### Related (same release)\n\nVersion 3.9.3 also tightens the `hasXSS()` regex that was designed as a secondary filter on detected language values. The previous pattern `/\u003c\\s*\\w+\\s*on\\w+\\s*=.*?\u003e/i` only matched event handlers in the **first** attribute position, so payloads like `\u003cinput autofocus onfocus=alert(1)\u003e` bypassed the filter. Applications that rendered `res.locals.language` into HTML with a context-unsafe templating mode (EJS `\u003c%- %\u003e`, Pug `!{\u2026}`, Handlebars `{{{\u2026}}}`) could be XSSed despite the filter being in place. This bypass is noted here because it is fixed in the same release, but the primary vulnerability reported in this advisory is the CRLF/header-injection path above.\n\n### Affected versions\n\n`\u003c 3.9.3`.\n\n### Patch\n\nFixed in **3.9.3**. The patch introduces `utils.sanitizeHeaderValue(str)` which strips `\\r`, `\\n`, and other C0/C1 control characters, and replaces both `utils.escape(lng)` call sites in `lib/index.js` with it. The `hasXSS()` regex has also been tightened to match event-handler attributes at any position.\n\n### Workarounds\n\nNo workaround short of upgrading. Front-proxying the middleware with a WAF rule that rejects `\\r`/`\\n` in query parameters, cookies, and path segments is a partial mitigation.\n\n### Credits\n\nDiscovered via an internal security audit of the i18next ecosystem.",
  "id": "GHSA-c3h8-g69v-pjrg",
  "modified": "2026-04-22T20:25:49Z",
  "published": "2026-04-22T20:25:49Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/i18next/i18next-http-middleware/security/advisories/GHSA-c3h8-g69v-pjrg"
    },
    {
      "type": "WEB",
      "url": "https://github.com/i18next/i18next-http-middleware/commit/65301c194593d46a84623b64e5fde2f51d3550f6"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/i18next/i18next-http-middleware"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "i18next-http-middleware: HTTP response splitting and DoS via unsanitised Content-Language header"
}