GHSA-c3h8-g69v-pjrg i18next-http-middleware: HTTP response splitting and DoS via unsanitised Content-Language header

• npm i18next-http-middleware: < 3.9.3 → fixed in 3.9.3

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` (/i` only matched event handlers in the first attribute position, so payloads like `` 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.