CVE-2023-44487: the HTTP/2 Rapid Reset attack

02Why did it break records?

HTTP/2 multiplexes many streams over one connection and caps how many can be active at once using SETTINGS_MAX_CONCURRENT_STREAMS, typically 100 or 128. In a normal flood, that cap plus the round-trip time limits how many requests a client can keep in flight. Rapid Reset removes both limits.

When a stream is reset it immediately becomes closed, and closed streams do not count toward the concurrency cap. So the attacker never exceeds the advertised limit, yet keeps the server perpetually busy setting up and tearing down streams: allocating stream state, decompressing headers, parsing the request, and often proxying it to a backend before the cancellation is even processed. The client pays almost nothing; the server pays for every request. That asymmetry is what made it an amplifier at the application layer.

03How does the attack work, step by step?

At a conceptual level, the loop is: open a stream with a full request, then cancel it before the response comes back. There are two documented variants beyond the basic form, which is why counting client resets alone was not a complete defence.

The basic form abuses request cancellation, a legitimate feature browsers use when a user navigates away. The non-cancelling variant does not reset anything; it simply opens more streams than allowed, which is why servers also had to close connections that exceed the stream limit rather than only limiting resets.

• Basic Rapid Reset: send HEADERS (with END_STREAM) then an immediate RST_STREAM, repeatedly
• Batched variant: open a large batch of streams, wait briefly, cancel them all, then open another batch
• Non-cancelling variant: open more concurrent streams than the server advertised, without resetting at all
• In every case the server does real work for requests that are never completed from the client's side

04Which servers patched how?

Because it is a protocol weakness, almost every HTTP/2 implementation shipped a fix within days or weeks of the 10 October 2023 disclosure. The fixes share a theme: account for streams that are reset or cancelled, and close the whole connection when a client's behaviour looks abusive, rather than trying to block individual requests.

F5 noted that nginx with default settings was largely protected already, because the default keepalive_requests limit of 1,000 caps how many requests a single connection can make; the patch tightened stream-rate handling further. The lesson across vendors is that the fix is operational, not a single magic value; the other nginx limits that matter in a flood are covered in nginx DDoS protection.

05What stops it, and what does not?

The vendor guidance converged on one principle: you cannot usefully block individual requests, because by the time you decide a request is abusive the stream is already closed. The whole TCP connection has to be torn down when abuse is detected.

• Track per-connection statistics: a connection with many requests of which a large share are cancelled is a strong candidate for teardown (Google's example: more than 100 requests with over 50% cancelled)
• Close connections that exceed the stream limit, to cover the non-cancelling variant
• Keep server stream limits and keepalive request caps at sane defaults
• Apply rate limiting and connection limits as supporting controls, not as the sole defence
• Do not rely on GOAWAY alone — it does not stop inbound requests fast enough

06How do you detect it in logs?

The fingerprint is a high rate of requests that never complete normally, concentrated on a small number of connections, with CPU high but bandwidth ordinary. In nginx access logs, HTTP/2 requests the client cancelled typically surface as status 499 (client closed the request), which Cloudflare also observed during the attacks. A per-connection count of 499s is a useful triage signal.

Treat the threshold below as illustrative and tune it to your traffic; a few cancellations per connection are normal browser behaviour. Envoy's advisory describes the same signal as elevated downstream_rq_http2_total without a substantial rise in downstream_cx_active. For the step-by-step response during an incident, see how to stop a DDoS attack.

# log format must include $connection and $server_protocol, e.g.:
# log_format h2 '$remote_addr conn=$connection $server_protocol $status "$request"';
# fields: $1 address, $2 conn=N, $3 protocol, $4 status

# connections with more than 100 cancelled HTTP/2 requests
awk '$3=="HTTP/2.0" && $4==499 {n[$1" "$2]++}
     END {for (k in n) if (n[k]>100) print n[k], k}' access.log

07The sequel: MadeYouReset

The Rapid Reset mitigation — count and limit client resets — was itself bypassed in 2025 by a technique that makes the server issue the reset instead of the client. That is MadeYouReset (CVE-2025-8671), and it is the natural next read if you are hardening HTTP/2. A third HTTP/2 denial of service, the CONTINUATION flood (CVE-2024-27316), abuses header frames rather than resets.