A continuation flood is a type of denial-of-service (DoS) attack method that can result from certain implementations of the HTTP/2 protocol, and specifically HTTP/2 CONTINUATION frames. By sending endless frames containing junk data, it's possible to sever backend connections and exhaust web server resources.
While HTTP/1.1 servers were particularly vulnerable to continuation floods, researchers soon determined that many popular HTTP/2 web servers were also at risk. This discovery was critical given that 33.3% of websites use HTTP/2 — and thus invite protocol abuse without fixes in place.
Multiple CVEs have been assigned across these vendors. The continuation flood attack method also appeared in the wild after HTTP/2 Rapid Reset, and — despite having the same severity score of 7.5 — has more damage potential. Bartek Nowotarski, a security researcher, first discovered the attack method in April 2024.
How do continuation flood attacks work?
HTTP/2 uses headers composed of header fields, which contain information in the form of key-value pairs. These details enable HTTP communication between client and server. Multiple header fields are organized into larger header lists, and these lists are compressed before being split into header block units — which are divided into smaller header block fragments.
The protocol distributes these fragments between HEADERS, PUSH_PROMISE, and CONTINUATION frames to keep payloads organized and easily digestible while transmitting requests and responses. Attackers can send HEADERS frames, then subsequently send an uncapped wave of CONTINUATION frames.
This is made possible by omitting the END_HEADERS flag from these message sequences, forcing the web server to process endless streams of HTTP/2 requests. This flag, when set properly, normally signals the completion of a frame sequence. Headers are stored in-memory and can quickly consume all available memory and CPU resources. Massive service slowdowns and crashes often result.
Responses and threat outlook
Continuation flood attacks have historically been difficult to pin down using HTTP traffic logs, making them harder to detect without closer analysis. They're also easy to orchestrate with small amounts of data over a single TCP connection. By comparison, other attacks like HTTP/2 Rapid Reset require a DDoS approach and more resources.
Luckily, the vast majority of HTTP/2 web servers quickly released patches to mitigate these attacks. Although the risk hasn't completely vanished, most unpatched servers (and their respective websites) using vulnerable HTTP/2 implementations aren't popular enough to grab an attacker's attention.
Does HAProxy protect against continuation floods?
Yes, and our implementation of HTTP/2 is resilient against continuation flood attacks — capable of processing upwards of 1,000,000 CONTINUATION frames per CPU core (dependent on CPU type).
To learn more about continuation floods in depth and HAProxy's proactive HTTP/2 implementation, please read our HAProxy is Resilient to the HTTP/2 CONTINUATION Flood blog announcement.