An HTTP/2 CONTINUATION flood is a Layer 7 (application) attack vector, one of the protocol-abuse classes a thorough DDoS test is built to exercise. It abuses the way HTTP/2 splits a single request's header block across frames: a client opens a stream, sends a HEADERS frame, and then streams an unbounded sequence of CONTINUATION frames without ever setting the END_HEADERS flag. The server keeps receiving header fragments for a request that never completes, appending each one to a growing per-stream buffer and, in vulnerable implementations, burning CPU on repeated HPACK decompression. A single connection can drive a server to out-of-memory or full CPU saturation, often without producing a single log line.
How the frame abuse works
HTTP/2 carries request headers in a HEADERS frame, and when a header block is too large for one frame the protocol allows it to spill into one or more CONTINUATION frames. The block is only considered complete when a frame arrives with the END_HEADERS flag set. The vulnerability class disclosed in 2024 is simple: never set that flag. The attacker sends HEADERS, then CONTINUATION, then CONTINUATION, indefinitely.
The damage comes from where the accounting failed. Several server and library implementations counted a request against connection limits, stream-concurrency caps, and request-logging only once the header block finished. Until END_HEADERS arrived, the half-parsed request was invisible to those controls, yet its partial header state sat in memory and its fragments kept feeding the HPACK decompressor. That is the worst combination for a defender: unbounded resource consumption that the platform's own counters do not see.
This makes the CONTINUATION flood a close cousin of HTTP/2 Rapid Reset, the other 2024-era HTTP/2 resource attack, and structurally a protocol attack rather than a raw volumetric one. It does not need a botnet or high bandwidth. It needs one open stream and a server that forgot to bound header parsing.
Why it matters under attack
The reason this vector is dangerous is that it is quiet and cheap. A classic HTTP flood announces itself in request-rate graphs; you can see the requests-per-second climb and reason about a threshold. A CONTINUATION flood sends what looks like the opening of one ordinary request and then simply never finishes it, so the request counter barely moves while memory climbs. In that sense it behaves like a low-and-slow attack: low packet volume, high resource cost, and a signature that per-request rate limits are structurally blind to.
The defensive fix is a hard cap: bound the total size of a header block and the number of CONTINUATION frames per stream, and drop the stream when either limit is crossed, before the request is considered complete. Whether a given deployment actually enforces that cap depends on the exact server version, the reverse proxy in front of it, and the HTTP/2 library each one links. Two hosts behind the same edge can differ, because the frame handling lives in the component that terminates HTTP/2, not in the WAF ruleset above it.
What a DDoS test measures
Because this is an application-layer attack that hides below the rate-limiting surface, testing for it is a targeted protocol exercise, not a bandwidth run. A test opens an HTTP/2 connection to the public entry point, sends a HEADERS frame, and then withholds END_HEADERS while feeding controlled CONTINUATION frames, watching whether the terminating server enforces a frame-count or header-size ceiling or lets the buffer grow.
The measurement that matters is where the request is bounded and where it is not. An edge that terminates HTTP/2 and enforces a strict header-block cap will reset the offending stream and protect the origin. An edge that passes HTTP/2 through to an unpatched origin, or one whose own library predates the fix, will let a single connection walk memory upward. The output is concrete: the maximum header-block size and CONTINUATION-frame count each hop tolerates before it drops the stream, and which component in the chain, if any, is the one holding the line. That turns a CVE headline into a per-hop statement about your own stack.
For how protocol-abuse vectors like this one sit alongside volumetric and reflection classes, see understanding DDoS attack vectors.