CVE-2026-23527
BaseFortify
Publication date: 2026-01-15
Last updated on: 2026-04-13
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| h3js | h3 | to 1.15.5 (exc) |
| h3js | h3 | 1.15.5 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-444 | The product acts as an intermediary HTTP agent (such as a proxy or firewall) in the data flow between two entities such as a client and server, but it does not interpret malformed HTTP requests or responses in ways that are consistent with how the messages will be processed by those entities that are at the ultimate destination. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-23527 is a critical HTTP Request Smuggling vulnerability in the h3 JavaScript framework prior to version 1.15.5. The issue arises because the function readRawBody performs a case-sensitive check for the 'Transfer-Encoding' header, specifically looking for the exact string 'chunked'. According to RFC standards, this header is case-insensitive, but h3 fails to recognize mixed-case variants like 'ChuNked'. When a request contains such a mixed-case 'Transfer-Encoding: ChuNked' header without a 'Content-Length' header, h3 incorrectly assumes the request body is empty and processes the request immediately, leaving the actual body data on the socket. This leads to a TE.TE desynchronization attack (HTTP Request Smuggling) when h3 is used behind certain proxies or load balancers that do not normalize headers, allowing attackers to smuggle requests past security controls or cause connection issues. [1]
How can this vulnerability impact me? :
This vulnerability can allow attackers to perform HTTP Request Smuggling attacks, which can bypass Web Application Firewalls (WAFs) or cause socket desynchronization issues. In environments where h3 is deployed behind TCP load balancers or proxies that do not normalize HTTP headers, attackers can exploit this flaw to smuggle malicious HTTP requests past security controls, potentially poisoning other users' connections or causing unexpected behavior in the application. This can lead to high confidentiality and integrity impacts, such as unauthorized access or data manipulation. [1]
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by sending HTTP requests with mixed-case variations of the Transfer-Encoding header, such as "Transfer-Encoding: ChuNked", without a Content-Length header and observing if the server incorrectly processes the request body. A practical detection method is to craft such requests and monitor if the server responds immediately without reading the body, indicating the vulnerability. Network packet inspection tools like tcpdump or Wireshark can be used to capture and analyze such requests and responses. Specific commands might include using curl or netcat to send crafted requests, for example: `printf 'POST / HTTP/1.1\r\nHost: vulnerable-host\r\nTransfer-Encoding: ChuNked\r\n\r\nBODY' | nc vulnerable-host 80` and observing the response behavior. [1]
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to upgrade the h3 framework to version 1.15.5 or later, where the vulnerability is fixed by making the Transfer-Encoding header check case-insensitive. If upgrading is not immediately possible, as a temporary workaround, ensure that any proxies or load balancers in front of h3 normalize HTTP headers to lowercase to prevent mixed-case Transfer-Encoding headers from reaching the vulnerable application. Additionally, monitor and block suspicious requests with mixed-case Transfer-Encoding headers at the network perimeter. [1, 2]