GHSA-MP2G-9VG9-F4CG

Vulnerability from github – Published: 2026-01-15 20:10 – Updated: 2026-01-15 22:34
VLAI?
Summary
h3 v1 has Request Smuggling (TE.TE) issue
Details

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())

Severity ?
8.9 (High)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.15.4"
      },
      "package": {
        "ecosystem": "npm",
        "name": "h3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.15.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-23527"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-444"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-15T20:10:51Z",
    "nvd_published_at": "2026-01-15T20:16:05Z",
    "severity": "HIGH"
  },
  "details": "I was digging into h3 v1 (specifically v1.15.4) and found a critical HTTP Request Smuggling vulnerability.\n\nBasically, `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.\n\n**The Bug**: If I send a request with Transfer-Encoding: ChuNked (mixed case), h3 misses it. Since it doesn\u0027t see \"chunked\" and there\u0027s no Content-Length, it assumes the body is empty and processes the request immediately.\n\nThis 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\u0027t normalize headers (like AWS NLB or Node proxies).\n\n**Vulnerable Code** (`src/utils/body.ts`):\n\n```js\nif (\n    !Number.parseInt(event.node.req.headers[\"content-length\"] || \"\") \u0026\u0026\n    !String(event.node.req.headers[\"transfer-encoding\"] ?? \"\")\n      .split(\",\")\n      .map((e) =\u003e e.trim())\n      .filter(Boolean)\n      .includes(\"chunked\") // \u003c--- This is the issue. \"ChuNkEd\" returns false here.\n  ) {\n    return Promise.resolve(undefined);\n  }\n```\n\nI verified this locally:\n\n- Sent a `Transfer-Encoding: ChunKed` request without a closing 0 chunk.\n- Express hangs (correctly waiting for data).\n- h3 responds immediately (vulnerable, thinks body is length 0).\n\n**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\u0027 connections.\n\n**Fix**: Just need to normalize the header value before checking: ` .map((e) =\u003e e.trim().toLowerCase())`",
  "id": "GHSA-mp2g-9vg9-f4cg",
  "modified": "2026-01-15T22:34:08Z",
  "published": "2026-01-15T20:10:51Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/h3js/h3/security/advisories/GHSA-mp2g-9vg9-f4cg"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23527"
    },
    {
      "type": "WEB",
      "url": "https://github.com/h3js/h3/commit/618ccf4f37b8b6148bea7f36040471af45bfb097"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/h3js/h3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/h3js/h3/releases/tag/v1.15.5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "h3 v1 has Request Smuggling (TE.TE) issue"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Detection rules are retrieved from Rulezet.