i18next-http-middleware: HTTP response splitting and DoS via unsanitised Content-Language header

### Summary Versions 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` (< 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('Content-Language', ...)` verbatim. ### Impact Two concrete outcomes depending on the Node.js version: - **Node.js < 14.6.0 — 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: - Session fixation via an injected `Set-Cookie` - Cache poisoning (injecting `Location`, `Content-Type`, etc.) - Reflected XSS in controlled response bodies - **Node.js ≥ 14.6.0 — 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). The 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. ### Related (same release) Version 3.9.3 also tightens the `hasXSS()` regex that was designed as a secondary filter on detected language values. The previous pattern `/<\s*\w+\s*on\w+\s*=.*?>/i` only matched event handlers in the **first** attribute position, so payloads like `<input autofocus onfocus=alert(1)>` bypassed the filter. Applications that rendered `res.locals.language` into HTML with a context-unsafe templating mode (EJS `<%- %>`, Pug `!{…}`, Handlebars `{{{…}}}`) 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. ### Affected versions `< 3.9.3`. ### Patch Fixed 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. ### Workarounds No 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. ### Credits Discovered via an internal security audit of the i18next ecosystem.

Source published

22 Apr 2026 20:25:49 UTC

Source modified

13 May 2026 13:52:05 UTC

Observed here

24 Oct 2026 13:17:17 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS_V3 · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:L

Publisher rating · HIGH