CVE-2026-44433
MediumCVSS 5.3Exploitation Probability (EPSS)
Low risk16th percentile - higher than 16% of all known CVEs
Summary
In the Quicly implementation of the QUIC protocol, primarily used in the H2O HTTP server, prior to commit 8b178e6, an attacker could send a STREAM frame with a single byte at the largest allowed offset to obtain additional flow control credit. Under certain conditions, this led to memory exhaustion because the application allocated a receive buffer for all out-of-order data up to the largest received offset.
Risk Assessment
The organization is exposed to a Denial of Service (DoS) attack that exhausts server memory by sending only a few packets. For the H2O server with default settings, this vulnerability increases the maximum memory allocated per connection by about 4 times.
Recommendation
Immediately update the Quicly library to a version containing commit 8b178e6 or later. For the H2O server, also review the stream concurrency control configuration to mitigate the risk.
Other vulnerabilities in Quicly
See all- CVE-2026-44436High
Quicly, the QUIC implementation in H2O, before commit 8b178e6 is vulnerable to a DoS attack via connection state corruption. The library accepts Connection IDs up to 255 bytes, but CID buffers are limited to 20 bytes, leading to buffer overrun and assertion failures.
- CVE-2026-44435High
In the Quicly IETF QUIC protocol implementation, primarily used within the H2O HTTP server, an assertion failure occurs prior to commit 937d0e9. The failure is triggered when the total number of valid handshake messages received over a CRYPTO stream in a single packet number space exceeds 32KB, causing a Denial of Service (DoS).
- CVE-2026-44434Medium
Quicly, a QUIC protocol implementation primarily used in the H2O HTTP server, was vulnerable to stateless reset injection before commit dccf5d4 due to missing packet entry validation. This allowed an on-path attacker to reset QUIC connections.
Original NVD description (English source)
Quicly is an IETF QUIC protocol implementation intended primarily for use within the H2O HTTP server. Prior to commit 8b178e6, an adversarial peer could send a STREAM frame carrying just one byte at the largest offset being permitted to obtain additional flow control credit, which under certain circumstances could lead to a Denial of Service. Assuming the application prepares a receive buffer for storing all data that arrive out-of-order, up to the largest offset being received, this behavior could lead to the application allocating large amount of memory with the peer sending only a handful of packets, resulting in memory exhaustion. In addition to the receive buffer allocation strategy, the severity of this vulnerability depends on how the application controls the stream concurrency. In case of the H2O HTTP server, under its default setting, this bug increases the maximum amount of memory allocated per connection by about 4 times. This issue has been fixed by commit 8b178e6.