What is the CVSS score of CVE-2026-55213?

CVE-2026-55213 has a CVSS 3.1 base score of 7.5 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. EPSS exploitation probability: 0.3%.

Which versions of h2o are affected by CVE-2026-55213?

h2o HTTP server deployments are vulnerable to a denial of service attack that can crash production servers without requiring authentication; no public exploit has been identified at time of analysis.

How to fix or mitigate CVE-2026-55213?

Within 24 hours: Inventory all h2o deployments and assess HTTP/3 exposure (check if HTTP/3 is enabled in production). Within 7 days: Deploy WAF rules to filter malformed QPACK frames, implement rate limiting on HTTP/3 connections, and consider disabling HTTP/3 if not business-critical until a patch is released. Within 30 days: Subscribe to h2o project security advisories, evaluate migration to alternative HTTP servers (nginx, Apache httpd) if patch remains unavailable, and conduct tabletop exercise for service outage scenarios.

h2o CVE-2026-55213

EUVD-2026-43036 HIGH

Memory Allocation with Excessive Size Value (CWE-789)

2026-07-10 GitHub_M

Denial Of Service H2O

7.5

CVSS 3.1 · Vendor: GitHub_M

Severity by source

Vendor (GitHub_M) PRIMARY

7.5 HIGH

AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

vuln.today AI

5.9 MEDIUM

Network-reachable and unauthenticated (AV:N/PR:N/UI:N) but only crashes musl-libc builds with HTTP/3 enabled, a deployment-specific precondition (AC:H); availability-only impact (A:H), no C/I.

3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

4.0 AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

None

Availability

High

Lifecycle Timeline

Analysis Generated

Jul 10, 2026 - 21:40 vuln.today

DescriptionCVE.org

h2o is an HTTP server with support for HTTP/1.x, HTTP/2 and HTTP/3. Prior to commit edd7a120bfc4af11ac0cbebce2a43cc1f93f9af1, when h2o processes a QPACK instruction sent from the peer over HTTP/3, lib/http3/qpack.c might allocate an on-stack buffer as large as approximately 800 KB by calling alloca, which exceeds the default pthread stack size used by musl libc and causes the h2o server to crash with a segmentation fault while touching the guard page. This issue is fixed in commit edd7a120bfc4af11ac0cbebce2a43cc1f93f9af1.

AnalysisAI

Remote unauthenticated denial of service in the h2o HTTP server (all versions prior to commit edd7a120bfc4af11ac0cbebce2a43cc1f93f9af1) allows an attacker to crash the server by sending a crafted QPACK instruction over HTTP/3. The flaw causes lib/http3/qpack.c to allocate an ~800 KB on-stack buffer via alloca, overflowing the default musl libc pthread stack and segfaulting on the guard page. No public exploit identified at time of analysis, and the issue is not listed in CISA KEV; impact is limited to availability with no data exposure.

Technical ContextAI

h2o is a high-performance HTTP server supporting HTTP/1.x, HTTP/2, and HTTP/3 (QUIC). QPACK is the HTTP/3 header-compression scheme (RFC 9204), the HTTP/3 analogue of HPACK, which uses dynamic-table encoder/decoder instructions exchanged between peers. In lib/http3/qpack.c the size of an on-stack buffer is derived from attacker-influenced QPACK instruction values and allocated with alloca(). This maps to CWE-789 (Memory Allocation with Excessive Size Value): the allocation size is not properly bounded, so a large value (~800 KB) exceeds musl libc's small default per-thread stack size, causing the process to touch the stack guard page and receive SIGSEGV. glibc's larger default stack (typically 8 MB) would generally absorb the same allocation, so the crash is specific to musl-based builds (e.g., Alpine Linux). The single affected CPE is cpe:2.3:a:h2o:h2o.

RemediationAI

Upstream fix available (PR/commit); released patched version not independently confirmed - update h2o to a build that includes commit edd7a120bfc4af11ac0cbebce2a43cc1f93f9af1 (see the advisory at https://github.com/h2o/h2o/security/advisories/GHSA-432c-8xmj-frmq and the commit at https://github.com/h2o/h2o/commit/edd7a120bfc4af11ac0cbebce2a43cc1f93f9af1). If you cannot rebuild immediately, the most effective compensating control is to disable HTTP/3/QUIC listeners in the h2o configuration, which fully removes the QPACK attack surface at the cost of losing HTTP/3 performance benefits (clients transparently fall back to HTTP/2 or HTTP/1.1). As an alternative for musl-based deployments, running h2o with a larger pthread stack size or rebuilding against glibc avoids the guard-page crash, but these are stopgaps that do not fix the unbounded allocation itself. Blocking or rate-limiting UDP/443 (QUIC) at the network edge for untrusted sources also reduces exposure while awaiting the rebuild.