EUVD-2026-309298

fkie_cve-2026-41683

i18next-http-middleware is a middleware to be used with Node.js web frameworks like express or Fastify and also for Deno. Prior to version 3.9.3, i18next-http-middleware 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. This issue has been patched in version 3.9.3.

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

Affected: npm: i18next-http-middleware

### 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 mid…

Most recent entries from all

EUVD-2026-309298

fkie_cve-2026-41683

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