CVE-2026-41683
HTTP Header Injection in i18next-http-middleware
Publication date: 2026-05-08
Last updated on: 2026-05-08
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| i18next | http-middleware | to 3.9.3 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-79 | The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users. |
| CWE-113 | The product receives data from an HTTP agent/component (e.g., web server, proxy, browser, etc.), but it does not neutralize or incorrectly neutralizes CR and LF characters before the data is included in outgoing HTTP headers. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
The vulnerability exists in i18next-http-middleware versions prior to 3.9.3, which is used with Node.js web frameworks like express or Fastify. The middleware writes user-controlled language values into the Content-Language response header after encoding them with an HTML-entity encoder that does not remove carriage return, line feed, or other control characters.
When used with older versions of i18next (before 19.5.0) that use a backward-compatibility fallback, an attacker can inject CRLF (carriage return and line feed) sequences into the lng parameter. These sequences reach the response header verbatim, potentially allowing HTTP response splitting or header injection attacks.
This issue was fixed in version 3.9.3 of i18next-http-middleware.
How can this vulnerability impact me? :
This vulnerability can allow an attacker to perform HTTP response splitting or header injection by injecting CRLF sequences into the Content-Language response header.
Such attacks can lead to security issues including cross-site scripting (XSS), cache poisoning, or web cache deception, which can compromise the integrity and confidentiality of the web application.
The CVSS score of 8.6 indicates a high severity, with impacts on confidentiality, integrity, and availability.
What immediate steps should I take to mitigate this vulnerability?
To mitigate this vulnerability, upgrade i18next-http-middleware to version 3.9.3 or later, where the issue has been patched.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability CVE-2026-41683 allows attackers to perform HTTP response splitting and denial-of-service attacks by injecting unsanitized user-controlled values into HTTP headers. This can lead to session fixation, cache poisoning, and reflected cross-site scripting (XSS), which may compromise the confidentiality and integrity of user data.
Such security issues can impact compliance with common standards and regulations like GDPR and HIPAA, which require protecting personal data against unauthorized access and ensuring data integrity. Exploitation of this vulnerability could result in unauthorized data exposure or service disruption, potentially violating these regulatory requirements.
Therefore, organizations using affected versions of i18next-http-middleware should upgrade to version 3.9.3 to mitigate these risks and maintain compliance.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring HTTP responses for unsanitized or malicious Content-Language headers that contain carriage return (CR) or line feed (LF) characters injected via the lng parameter.
One approach is to capture and inspect HTTP requests and responses to identify if the lng parameter is being used to inject CRLF sequences that lead to HTTP response splitting or header injection.
You can use network traffic analysis tools like tcpdump or Wireshark to capture HTTP traffic and then grep or filter for suspicious Content-Language headers or query parameters containing CR or LF characters.
- Use tcpdump to capture HTTP traffic on port 80 or 443 (if unencrypted): tcpdump -A -s 0 'tcp port 80'
- Filter captured traffic for requests containing the lng parameter with potential CRLF characters: grep -P '\rlng=|\n' captured_traffic.txt
- Inspect HTTP response headers for unexpected Content-Language values containing control characters: grep -P 'Content-Language:.*(\r|\n)' captured_traffic.txt
Additionally, testing the application by sending crafted HTTP requests with CRLF sequences in the lng parameter and observing if the Content-Language header reflects these sequences can help confirm the vulnerability.
- Example curl command to test injection: curl -v 'http://targetsite/?lng=en%0d%0aInjected-Header: injected'