Quicly CVE-2026-44433

The attack requires network access to the server's QUIC UDP port and that the Quicly-based application (specifically H2O) be configured to support QUIC/HTTP-3. Exploitation severity scales with two configuration factors: first, the application's receive buffer allocation strategy - the vulnerability is most severe when a contiguous buffer is allocated from offset 0 to the largest received offset to accommodate out-of-order data; second, the stream concurrency limit - under H2O's default settings, enough concurrent streams are permitted to amplify memory consumption approximately 4x per connection. Applications that pre-allocate only sparse or bounded buffers for out-of-order data would see reduced impact. No authentication, user interaction, or special session state is required. Exploitation is limited to environments actually running H2O with QUIC enabled; plain HTTP/1.1 or HTTP/2 deployments are unaffected.

The CVSS base score of 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) accurately reflects a remotely exploitable, unauthenticated network attack requiring no user interaction, with high availability impact. However, real-world risk is substantially lower than the raw score implies. EPSS of 0.25% (16th percentile) is very low, indicating minimal observed exploitation interest from the broader threat landscape. SSVC classifies exploitation as 'none' and technical impact as 'partial', consistent with a targeted DoS rather than mass exploitation. The attack is SSVC-automatable (yes), meaning it could be scripted and repeated, but H2O is a niche HTTP server with limited deployment compared to nginx or Apache, which bounds the actual attack surface. The vulnerability requires that the application use a contiguous receive buffer strategy and that stream concurrency be non-trivially high - under H2O defaults the 4x amplification is confirmed, but tighter stream concurrency limits would reduce severity. KEV status is absent, and no POC has been identified. Overall, this is a legitimate DoS concern for H2O operators but not a priority for environments not running H2O or Quicly.

An attacker with network access to an H2O server's QUIC UDP port opens a connection and sends a small number of STREAM frames, each carrying a single byte positioned at the maximum flow-control-permitted stream offset. The server's receive buffer manager allocates memory up to the advertised offset for each stream to handle anticipated out-of-order segments, consuming memory vastly disproportionate to the bytes actually transferred. By opening multiple concurrent streams (permissible under H2O's default configuration) and repeating this pattern across connections, the attacker exhausts available memory and crashes or degrades the server. No public POC has been identified.