HTTP/2 CONTINUATION Flood (CVE-2024-27316)

02How does the attack work, conceptually?

An HTTP/2 server must maintain HPACK compression state across every HEADERS and CONTINUATION frame on a connection, because the header table is shared. That forces it to process each frame as it arrives, even before it has a complete request. A correct implementation caps how much header data, or how many continuation frames, it will accept before it gives up and resets the stream.

In most vulnerable implementations that cap was missing or applied too late. The server accepted CONTINUATION frames indefinitely while the END_HEADERS flag stayed unset, so the stream never finished and was never reset. Where excess headers were buffered, memory grew until the process was killed. Where they were only decoded, CPU was consumed decoding Huffman-encoded data that is far cheaper to send than to decode. In several stacks a single TCP connection, sometimes a handful of frames, was enough.

This page describes the mechanism only. It contains no frame sequences, no tooling and no steps to reproduce an attack. The fix and the honest limits of edge filtering are in the sections below.

03Which implementations were affected, and which fixes apply?

The coordinated disclosure listed many implementations, each with its own CVE and fixed version. If you run any of these, match your deployed version against the fixed one. The researcher lists nginx, HAProxy, Jetty, NetScaler, Varnish and Cloudflare as not affected.

04How is it different from Rapid Reset and MadeYouReset?

All three abuse HTTP/2 stream handling, but the mechanics and the right defences differ. CONTINUATION Flood keeps a single stream open forever by withholding END_HEADERS, so the request never completes. Rapid Reset and MadeYouReset instead churn through many streams that are cancelled or reset, each freeing a concurrency slot so the next can start immediately.

The practical difference is visibility and scale. Rapid Reset generates visible requests and usually needs a botnet to do real damage, so rate limiting and request logging both help. CONTINUATION Flood generates no completed requests, so it is invisible in the access log, and in many servers a single connection suffices, so per-request rate limiting does not catch it. The fix for CONTINUATION Flood is a cap on continuation frames, not a rate limit.

• For the stream-cancellation record attacks, see HTTP/2 Rapid Reset
• For the server-induced variant that bypasses Rapid Reset defences, see MadeYouReset
• For the broader category these sit in, see what an HTTP flood is

05How do I check and fix it?

Check the version of every HTTP/2 endpoint you expose, including servers behind a load balancer and HTTP/2 client libraries in your own code. Confirm whether HTTP/2 is even enabled, then match the version against the fixed one in the table. The checks below read state only.

The fix is to upgrade to the patched version. Where an upgrade is not yet possible and the server offers HTTP/1.1, disabling HTTP/2 removes the attack surface entirely at the cost of HTTP/2's performance benefits. On Apache this is a one-line change to the Protocols directive; restart the server afterwards.

# does the endpoint negotiate HTTP/2 at all?
curl -sI --http2 https://example.com/ -o /dev/null -w '%{http_version}\n'

# server versions (match against the fixed-version table)
apache2 -v        # or: httpd -v
node --version
dpkg -l | grep -E 'apache2|nghttp2|nodejs'   # Debian/Ubuntu package versions

06What can a WAF or reverse proxy do about it?

Be precise about the limit. If the vulnerable server is the one terminating the HTTP/2 connection, a filter inside that same server cannot reliably save it, because the damage happens during header processing. The useful arrangement is a separate, non-vulnerable tier in front that terminates HTTP/2 itself.

A reverse proxy that is not affected, or that is patched, terminates the client connection and forwards clean, complete requests to the origin over a connection it controls. The malformed, never-ending header stream dies at that tier and never reaches the origin. This is the same reason a resilient proxy absorbs an HTTP flood before it reaches the application. What a proxy cannot do is make an unpatched origin safe if clients can still reach it directly, which is why edge filtering supplements patching rather than replacing it. For keeping clients off the origin address, see how to hide your origin IP.

07Timeline