CVE-2026-23527

H3 is a minimal H(TTP) framework built for high performance and portability. Prior to 1.15.5, there is a critical HTTP Request Smuggling vulnerability. readRawBody is doing a strict case-sensitive check for the Transfer-Encoding header. It explicitly looks for "chunked", but per the RFC, this header should be case-insensitive. This vulnerability is fixed in 1.15.5.

H3 is a minimal H(TTP) framework built for high performance and portability. Prior to 1.15.5, there is a critical HTTP Request Smuggling vulnerability. readRawBody is doing a strict case-sensitive check for the Transfer-Encoding header. It explicitly looks for "chunked", but per the RFC, this header should be case-insensitive. This vulnerability is fixed in 1.15.5.

I was digging into h3 v1 (specifically v1.15.4) and found a critical HTTP Request Smuggling vulnerability.

Basically, readRawBody is doing a strict case-sensitive check for the Transfer-Encoding header. It explicitly looks for "chunked", but per the RFC, this header should be case-insensitive.

The Bug: If I send a request with Transfer-Encoding: ChuNked (mixed case), h3 misses it. Since it doesn't see "chunked" and there's no Content-Length, it assumes the body is empty and processes the request immediately.

This leaves the actual body sitting on the socket, which triggers a classic TE.TE Desync (Request Smuggling) if the app is running behind a Layer 4 proxy or anything that doesn't normalize headers (like AWS NLB or Node proxies).

Vulnerable Code (src/utils/body.ts):

if (
    !Number.parseInt(event.node.req.headers["content-length"] || "") &&
    !String(event.node.req.headers["transfer-encoding"] ?? "")
      .split(",")
      .map((e) => e.trim())
      .filter(Boolean)
      .includes("chunked") // <--- This is the issue. "ChuNkEd" returns false here.
  ) {
    return Promise.resolve(undefined);
  }

I verified this locally:

• Sent a Transfer-Encoding: ChunKed request without a closing 0 chunk.
• Express hangs (correctly waiting for data).
• h3 responds immediately (vulnerable, thinks body is length 0).

Impact: Since H3/Nuxt/Nitro is often used in containerized setups behind TCP load balancers, an attacker can use this to smuggle requests past WAFs or desynchronize the socket to poison other users' connections.

Fix: Just need to normalize the header value before checking: .map((e) => e.trim().toLowerCase())

H3 is a minimal H(TTP) framework built for high performance and portability. Prior to 1.15.5, there is a critical HTTP Request Smuggling vulnerability. readRawBody is doing a strict case-sensitive check for the Transfer-Encoding header. It explicitly looks for "chunked", but per the RFC, this header should be case-insensitive. This vulnerability is fixed in 1.15.5.

H3 is a minimal H(TTP) framework built for high performance and portability. Prior to 1.15.5, there is a critical HTTP Request Smuggling vulnerability. readRawBody is doing a strict case-sensitive check for the Transfer-Encoding header. It explicitly looks for "chunked", but per the RFC, this header should be case-insensitive. This vulnerability is fixed in 1.15.5.

I was digging into h3 v1 (specifically v1.15.4) and found a critical HTTP Request Smuggling vulnerability.

Basically, readRawBody is doing a strict case-sensitive check for the Transfer-Encoding header. It explicitly looks for "chunked", but per the RFC, this header should be case-insensitive.

The Bug: If I send a request with Transfer-Encoding: ChuNked (mixed case), h3 misses it. Since it doesn't see "chunked" and there's no Content-Length, it assumes the body is empty and processes the request immediately.

This leaves the actual body sitting on the socket, which triggers a classic TE.TE Desync (Request Smuggling) if the app is running behind a Layer 4 proxy or anything that doesn't normalize headers (like AWS NLB or Node proxies).

Vulnerable Code (src/utils/body.ts):

if (
    !Number.parseInt(event.node.req.headers["content-length"] || "") &&
    !String(event.node.req.headers["transfer-encoding"] ?? "")
      .split(",")
      .map((e) => e.trim())
      .filter(Boolean)
      .includes("chunked") // <--- This is the issue. "ChuNkEd" returns false here.
  ) {
    return Promise.resolve(undefined);
  }

I verified this locally:

• Sent a Transfer-Encoding: ChunKed request without a closing 0 chunk.
• Express hangs (correctly waiting for data).
• h3 responds immediately (vulnerable, thinks body is length 0).

Impact: Since H3/Nuxt/Nitro is often used in containerized setups behind TCP load balancers, an attacker can use this to smuggle requests past WAFs or desynchronize the socket to poison other users' connections.

Fix: Just need to normalize the header value before checking: .map((e) => e.trim().toLowerCase())

TuxCare rebuilt h3 to address 2 CVEs. Fixed in 1.15.3-tuxcare.1.