CVE-2026-41683: i18next-http-middleware XSS Vulnerability

CVE-2026-41683 Overview

CVE-2026-41683 is an HTTP response splitting vulnerability in i18next-http-middleware, a localization middleware for Node.js frameworks such as Express, Fastify, and Deno. Versions prior to 3.9.3 write attacker-controlled language values into the Content-Language response header after passing them through utils.escape(). The escape routine performs HTML-entity encoding but does not strip carriage return (\r), line feed (\n), or other control characters. Attackers can inject CRLF sequences through the lng parameter to manipulate response headers and inject content. The maintainers patched the issue in version 3.9.3.

Critical Impact

Attackers can inject arbitrary HTTP headers and response content through the lng parameter, enabling header injection, cache poisoning, and reflected cross-site scripting against users of vulnerable applications.

Affected Products

• i18next-http-middleware versions prior to 3.9.3
• Node.js applications using Express or Fastify with the vulnerable middleware
• Deno applications integrating the vulnerable middleware

Discovery Timeline

• 2026-05-08 - CVE-2026-41683 published to NVD
• 2026-05-12 - Last updated in NVD database

Technical Details for CVE-2026-41683

Vulnerability Analysis

The vulnerability is a classic HTTP response splitting flaw [CWE-79] caused by incomplete output sanitization. The middleware reads a user-controlled language identifier from the request, typically the lng query parameter, and reflects it into the Content-Language header through res.setHeader('Content-Language', ...). Before writing the header, the middleware calls utils.escape(), an HTML-entity encoder designed to neutralize characters such as <, >, and &. That function does not handle CRLF or other control characters, so byte sequences like %0d%0a survive intact.

When the host application uses an older i18next release earlier than 19.5.0, the backward-compatibility fallback at LanguageDetector.js:100 returns the raw detected value rather than a validated locale code. The unfiltered string is then handed to setHeader, producing a header value that contains literal newlines. Downstream HTTP parsers interpret those newlines as header delimiters, allowing the attacker to terminate the Content-Language header and append additional headers or response body content.

Root Cause

The root cause is reliance on an HTML encoder for an HTTP header context. utils.escape() was designed to prevent cross-site scripting in HTML output and does not sanitize header-specific metacharacters. Header values must be validated against [RFC 7230] rules, which forbid CR, LF, and NUL bytes. Combined with i18next versions that do not normalize detected language codes, the middleware exposes a direct sink for header injection.

Attack Vector

An unauthenticated remote attacker crafts a request such as GET /?lng=en%0d%0aSet-Cookie:%20sid=evil against a vulnerable endpoint. The middleware reflects the decoded value into Content-Language, splitting the response into two logical headers. Variants of this payload can inject cache control directives, redirect headers, or full HTTP response bodies that load attacker-controlled scripts. Exploitation requires no privileges and no user interaction, and it is fully scriptable across any application running an affected version.

Detection Methods for CVE-2026-41683

Indicators of Compromise

• HTTP requests containing URL-encoded CRLF sequences (%0d%0a, %0A, %0D) in the lng query parameter, cookie, or Accept-Language header
• Application access logs showing unusually long or non-RFC-compliant values in language detection parameters
• Responses where the Content-Language header contains unexpected newlines or where additional headers appear immediately after it

Detection Strategies

• Inspect web application firewall logs for requests where language-related parameters contain control characters or encoded line terminators
• Audit Node.js dependency manifests (package.json, package-lock.json, yarn.lock) for i18next-http-middleware versions earlier than 3.9.3
• Add runtime assertions or proxy rules that reject any outbound Content-Language header containing characters outside the RFC 5646 language tag grammar

Monitoring Recommendations

• Forward Node.js application and reverse-proxy logs to a centralized analytics platform and alert on CRLF patterns in request parameters
• Track dependency drift across services with software composition analysis to surface vulnerable middleware versions as they appear
• Monitor for downstream effects such as unexpected Set-Cookie headers, cache poisoning anomalies, or reflected script payloads in client telemetry

How to Mitigate CVE-2026-41683

Immediate Actions Required

• Upgrade i18next-http-middleware to version 3.9.3 or later across all Node.js and Deno services
• Upgrade i18next to version 19.5.0 or later to remove the backward-compatibility fallback that produced raw detected values
• Audit application code for any other location that reflects request-derived data into response headers without strict validation

Patch Information

The maintainers fixed the issue in i18next-http-middleware version 3.9.3 by sanitizing the language value before it reaches res.setHeader('Content-Language', ...). Details are available in the GitHub Security Advisory GHSA-c3h8-g69v-pjrg.

Workarounds

• Place a reverse proxy or WAF rule in front of vulnerable services that rejects requests containing CRLF sequences in the lng parameter and Accept-Language header
• Constrain the supported language set in application code and validate the detected value against an allow list of RFC 5646 tags before any header write
• Remove or disable the Content-Language header emission until the dependency upgrade is completed

# Upgrade the vulnerable middleware and the underlying i18next library
npm install i18next-http-middleware@^3.9.3 i18next@^19.5.0
npm audit --production