h2o CVE-2026-55213

Exploitation requires that the target h2o server (1) has HTTP/3 enabled and reachable (QUIC over UDP, typically port 443) and (2) is built against musl libc, whose small default pthread stack (well under 800 KB) is what the alloca overruns - glibc builds with their much larger default stacks are generally not affected. Given the CVSS vector's PR:N/UI:N, no authentication or user interaction is needed once those conditions hold. The limiting factors are therefore the musl-libc build requirement (e.g., Alpine-based containers) and HTTP/3 being active; a glibc build or an HTTP/2-only deployment is not exploitable via this path.

The published CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H = 7.5 High) reflects a network-reachable, unauthenticated availability-only impact, which is consistent with the description. However, the real-world exploitability is narrower than the raw score suggests: the crash is triggered only when h2o is (a) built against musl libc and (b) serving HTTP/3 - under glibc the oversized alloca fits in the default stack. This deployment dependency argues for higher attack complexity (my independent assessment uses AC:H). There is no confidentiality or integrity impact - this is a pure crash/DoS, not code execution. No EPSS score, KEV listing, or POC was provided, so there is no evidence of active or automated exploitation; treat this as a patch-soon availability bug for musl-based HTTP/3 deployments rather than a critical emergency. EPSS is missing from the input and cannot be cited.

An attacker who can reach a musl-libc h2o instance over HTTP/3 opens a QUIC connection and sends a crafted QPACK encoder/decoder instruction whose length drives an ~800 KB alloca in qpack.c. The oversized stack allocation runs past musl's small default thread stack into the guard page, and the worker process crashes with a segmentation fault, dropping in-flight connections. No authentication or user interaction is needed, though no public POC was provided in the source data.