CVE-2026-55213: h2o HTTP Server DOS Vulnerability

CVE-2026-55213 Overview

CVE-2026-55213 is a denial-of-service vulnerability in the h2o HTTP server, which supports HTTP/1.x, HTTP/2, and HTTP/3. The flaw resides in the QPACK decoder implementation at lib/http3/qpack.c. When h2o processes a QPACK instruction sent by a peer over HTTP/3, the code uses alloca to allocate an on-stack buffer as large as approximately 800 KB. This size exceeds the default pthread stack size used by musl libc. Touching the guard page causes the h2o server to crash with a segmentation fault. The issue is fixed in commit edd7a120bfc4af11ac0cbebce2a43cc1f93f9af1 [CWE-789: Memory Allocation with Excessive Size Value].

Critical Impact
Remote unauthenticated attackers can crash h2o servers built against musl libc by sending crafted QPACK encoder instructions over HTTP/3.

Affected Products

h2o HTTP server versions prior to commit edd7a120bfc4af11ac0cbebce2a43cc1f93f9af1
Deployments linked against musl libc (default pthread stack size)
HTTP/3-enabled h2o server configurations

Discovery Timeline

2026-07-10 - CVE-2026-55213 published to NVD
2026-07-13 - Last updated in NVD database

Technical Details for CVE-2026-55213

Vulnerability Analysis

The h2o QPACK decoder processes header compression instructions received over HTTP/3 streams. The decoder relies on flow control performed by the caller to bound the maximum size of literal fields. When decoding a literal value or name, the implementation calls alloca to reserve a temporary buffer proportional to the literal length declared by the peer. Because the previous implementation did not enforce an internal cap and did not use the correct flow control size, a peer could induce allocations approaching 800 KB on the thread stack. Musl libc uses a small default pthread stack, so the allocation crosses the stack guard page and terminates the worker process. The result is a repeatable remote crash without authentication or user interaction.

Root Cause

The root cause is unbounded stack allocation controlled by attacker-supplied length fields in QPACK instructions. The decoder assumed that caller-side flow control limits would prevent oversized literals, but the receive window was not configured to match the assumption. The fix in lib/http3/qpack.c adds an assert_literal_length check and switches oversized allocations to the heap, while pinning the QPACK receive window to h2o_http3_calc_min_flow_control_size(H2O_MAX_REQLEN).

Attack Vector

An attacker establishes an HTTP/3 (QUIC) connection to a vulnerable h2o server and opens a QPACK encoder stream. The attacker sends encoder instructions declaring large literal name or value lengths. The decoder invokes alloca with the attacker-controlled size, overruns the pthread stack guard page, and the server process crashes. No prior authentication is required, and the attack succeeds over the network.

// Patch excerpt from lib/http3/qpack.c
// Source: https://github.com/h2o/h2o/commit/edd7a120bfc4af11ac0cbebce2a43cc1f93f9af1
     free(qpack);
 }

+static void assert_literal_length(size_t len)
+{
+    /* regarding this limit; see the doc-comment on h2o_qpack_decoder_handle_input */
+    assert(len <= h2o_http3_calc_min_flow_control_size(H2O_MAX_REQLEN));
+}
+
 static void decoder_insert(h2o_qpack_decoder_t *qpack, struct st_h2o_qpack_header_t *added)
 {
     ++qpack->insert_count;

The accompanying header comment in include/h2o/qpack.h was updated to require the caller to set the receive window to h2o_http3_calc_min_flow_control_size(H2O_MAX_REQLEN) so that flow control blocks oversized encoder instructions before they reach the decoder.

Detection Methods for CVE-2026-55213

Indicators of Compromise

Unexpected SIGSEGV termination of h2o worker processes coinciding with inbound HTTP/3 traffic
Core dumps showing faults in lib/http3/qpack.c allocation paths or alloca frames
Repeated QUIC connections from a single source followed by service restarts

Detection Strategies

Inspect QUIC/HTTP/3 traffic for QPACK encoder streams containing abnormally large literal length fields
Alert on abrupt h2o process restarts or systemd service failures on HTTP/3-facing hosts
Monitor kernel logs (dmesg, journalctl) for segmentation fault entries referencing h2o

Monitoring Recommendations

Track h2o crash counters and worker restart rates as a service-health signal
Ingest QUIC connection telemetry into a SIEM and baseline QPACK instruction sizes per client
Correlate spikes in HTTP/3 handshake failures with upstream QUIC source addresses to identify probing

How to Mitigate CVE-2026-55213

Immediate Actions Required

Update h2o to a build that includes commit edd7a120bfc4af11ac0cbebce2a43cc1f93f9af1 or later
Rebuild any custom h2o packages that link against musl libc from the patched source
Restart h2o instances after upgrade to load the fixed binary into all worker processes

Patch Information

The fix is available in the upstream repository via commit edd7a120bfc4af11ac0cbebce2a43cc1f93f9af1. Refer to the GitHub Security Advisory GHSA-432c-8xmj-frmq and the upstream commit for the code changes, including the new assert_literal_length check and heap-based allocation for large QPACK literals.

Workarounds

Disable HTTP/3 (QUIC) listeners in h2o.conf until the patched binary is deployed
Rebuild h2o against glibc, whose larger default pthread stack reduces exposure, if immediate patching is not possible
Increase the pthread stack size via pthread_attr_setstacksize as a defense-in-depth measure while a patch is prepared

bash

# Temporary mitigation: disable HTTP/3 in h2o.conf
# Comment out or remove the listen block that enables QUIC
#listen:
#  port: 443
#  type: quic
#  ssl:
#    certificate-file: /etc/h2o/server.crt
#    key-file: /etc/h2o/server.key

# Reload h2o after configuration change
sudo systemctl reload h2o