GHSA-c3h8-g69v-pjrg

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...