CVE-2026-41683

What it actually does

The vulnerability is an HTTP response header injection issue in i18next-http-middleware prior to 3.9.3. A user-controlled language value, commonly supplied through the `lng` request parameter, can be written into the `Content-Language` response header without removing carriage return and line feed characters. In affected configurations, especially when paired with older i18next versions before 19.5.0 or code paths that preserve a raw detected language value, an attacker can inject CRLF sequences into the response header stream. This can allow HTTP response splitting, injection of arbitrary response headers, cache poisoning, cookie manipulation, security-header bypass, open redirect behavior through injected headers, or reflected script delivery depending on the web framework, proxy, browser, and caching layer behavior.

Why it matters to the business

Applications using affected i18next-http-middleware versions may allow unauthenticated remote attackers to manipulate HTTP responses seen by users or intermediate caches. In practical terms, this can lead to users receiving attacker-controlled content, poisoned cached pages, weakened browser protections, session or cookie abuse, and reputational damage if public-facing web applications are affected. The CVSS score is high, but the currently reported EPSS is low and there is no known CISA KEV listing or ransomware association, so remediation should be prioritized for internet-facing Node.js, Express, Fastify, or Deno applications that accept language selection from requests.

How an attack unfolds

An attacker identifies an application using i18next-http-middleware for language detection and confirms that the application reflects a request-controlled language value into the `Content-Language` response header. The attacker then sends a crafted request containing encoded CRLF characters in the language parameter, such as in `lng`, followed by additional header content or response-splitting payloads. If the vulnerable middleware and compatible i18next behavior preserve the raw value, the server emits the injected newline sequence inside the HTTP response headers. The attacker can then attempt to add or override headers, manipulate cookies, alter caching behavior, redirect victims, or cause downstream proxies and browsers to interpret attacker-controlled content as part of the response. Successful impact depends on how the framework, Node.js runtime, reverse proxy, CDN, and browser handle invalid or split headers.

How to fix it

Upgrade i18next-http-middleware to version 3.9.3 or later. Also upgrade i18next to version 19.5.0 or later where possible to avoid legacy language-detection fallback behavior that can preserve raw detected values. Review all application code that sets response headers from request-controlled values and ensure CR, LF, NUL, and other control characters are rejected rather than HTML-escaped. If immediate upgrade is not possible, add input validation for language values using a strict allowlist of expected locale identifiers, such as `en`, `en-US`, `fr`, or `de-DE`, and reject or normalize any value containing control characters, percent-encoded CRLF sequences, or unexpected punctuation. As defense in depth, configure reverse proxies and application gateways to reject requests containing encoded newline characters in query strings, cookies, and headers where operationally safe.

How to confirm the fix worked

Confirm dependency versions in package manifests and lockfiles, including transitive dependencies, and verify that i18next-http-middleware is 3.9.3 or later. Confirm i18next is 19.5.0 or later where used with the middleware. Test representative application endpoints that perform language detection by sending a request with a language parameter containing encoded CRLF characters, for example a harmless test value with `%0d%0aX-Test-Header:%20crlf-test`. The fixed application should reject, sanitize, or ignore the value and must not emit an injected `X-Test-Header` or malformed `Content-Language` header. Also validate behavior through the full production-like request path, including CDN, load balancer, reverse proxy, application server, and browser-facing response, because exploitation may depend on intermediaries.

Typical attack path

1. Discover a web application that uses i18next-http-middleware for request language detection.
2. Identify a controllable language input such as the `lng` query parameter, cookie, header, path segment, or body field.
3. Submit benign test values and observe whether they influence the `Content-Language` response header.
4. Send a crafted value containing URL-encoded CRLF sequences such as `%0d%0a` or `%0D%0A`.
5. Append an injected header or response-splitting payload after the CRLF sequence.
6. Observe whether the response contains additional injected headers, malformed headers, altered cookies, cache directives, redirects, or attacker-controlled response content.
7. If exploitable, use the behavior for cache poisoning, browser security control bypass, session manipulation, or reflected script/content delivery.

How to detect it

To determine whether exploitation has already occurred, review HTTP access logs, reverse-proxy logs, CDN/WAF logs, application logs, and error logs for requests to localized endpoints or requests containing language parameters with encoded or raw carriage-return and line-feed characters. Focus on `lng`, `language`, `locale`, `i18next`, and similar language-selection inputs in query strings, cookies, headers, path parameters, and request bodies. Look for `%0d%0a`, `%0D%0A`, `%0a`, `%0d`, double-encoded variants such as `%250d%250a`, and anomalous values followed by header-like strings containing colons. Inspect response telemetry, if available, for unexpected headers, duplicate headers, malformed `Content-Language` values, unexpected `Set-Cookie`, `Location`, `Content-Security-Policy`, `Cache-Control`, `Refresh`, or `Access-Control-Allow-Origin` headers. Review CDN and proxy cache entries for localized pages that may have been poisoned or served with abnormal headers. In application logs, investigate exceptions related to invalid header characters, malformed header values, or failed response writes. If browser security telemetry or RUM data is available, correlate suspicious requests with unexpected redirects, script execution, cookie changes, or CSP violations.

• %0d%0a
• %0D%0A
• %0a
• %0A
• %0d
• %0D
• %250d%250a
• %250D%250A
• lng=%0d%0a
• lng=%0D%0A
• lng=%250d%250a
• lng=%250D%250A
• language=%0d%0a
• locale=%0d%0a
• i18next=%0d%0a
• Content-Language:
• X-Test-Header: crlf-test
• Set-Cookie:
• Location: http
• Location: https
• Content-Security-Policy:
• Access-Control-Allow-Origin:
• Cache-Control: public
• Refresh: 0
• Invalid character in header content
• ERR_INVALID_CHAR
• Cannot set headers after they are sent

What your security team should do

• Inventory applications using i18next-http-middleware, especially public-facing Node.js, Express, Fastify, and Deno services.
• Prioritize upgrading i18next-http-middleware to 3.9.3 or later and i18next to 19.5.0 or later where applicable.
• Search package-lock.json, yarn.lock, pnpm-lock.yaml, npm-shrinkwrap.json, and Deno dependency definitions for vulnerable versions.
• Add application-level allowlist validation for locale values and reject any language input containing CR, LF, NUL, or encoded newline sequences.
• Add WAF, CDN, or reverse-proxy detections for `%0d%0a`, `%0a`, and `%0d` in language-related parameters, while testing for false positives.
• Review HTTP response logs and proxy logs for injected or malformed headers associated with language-selection requests.
• Test critical web applications for response header injection using safe, non-destructive payloads after patching.
• Treat confirmed exploitation as a web-session and cache-integrity incident: review cache contents, cookie behavior, redirects, and security headers served during the exposure window.