HTTP/2 Rapid Reset Attack (CVE-2023-44487) — Technical Deep Dive

In October 2023, Cloudflare, Google, and AWS simultaneously disclosed CVE-2023-44487, a zero-day vulnerability in the HTTP/2 protocol that was actively exploited in the wild to generate the largest DDoS attacks ever recorded — peaking at 398 million requests per second.

How HTTP/2 multiplexing works

HTTP/2 introduced stream multiplexing: a single TCP connection can carry hundreds of concurrent request/response pairs (streams). Each stream has a unique ID and can be independently opened, used, and closed. Servers enforce a SETTINGS_MAX_CONCURRENT_STREAMS limit (typically 100'“256) to prevent resource exhaustion.

The key assumption was that clients would wait for responses before opening new streams. The Rapid Reset attack breaks this assumption.

The Rapid Reset exploit

The attacker opens a stream by sending a HEADERS frame, then immediately sends a RST_STREAM frame to cancel it — before the server has time to process the request. Because the stream is "closed," it no longer counts against MAX_CONCURRENT_STREAMS. The attacker repeats this millions of times per second:

1. Client sends HEADERS (stream 1) → Server allocates memory, begins processing.
2. Client immediately sends RST_STREAM (stream 1) → Stream is "closed," but the server already started work.
3. Client sends HEADERS (stream 3) → Repeat. The server's concurrent stream count never exceeds the limit, but its CPU is saturated processing and discarding half-finished requests.

The result: a single TCP connection can generate thousands of requests per second, and a modest botnet can generate hundreds of millions of RPS with minimal bandwidth.

Who is vulnerable?

Any server, reverse proxy, or load balancer that speaks HTTP/2 is potentially vulnerable. Major affected software included:

• Nginx — patched in 1.25.3
• Apache httpd — patched in 2.4.58
• HAProxy — patched in 2.8.4
• Envoy, Caddy, Node.js http2 — all released patches.
• Cloud providers — AWS ALB, Cloudflare, GCP HTTP(S) LB all deployed mitigations at the edge.

How to test your infrastructure

Patching is necessary but not sufficient. You need to verify that your infrastructure actually handles Rapid Reset traffic correctly under load. This requires:

• Generating HTTP/2 connections that perform the HEADERS → RST_STREAM loop at high frequency.
• Monitoring server CPU, memory, and response latency during the test.
• Verifying that your WAF or reverse proxy correctly rate-limits RST_STREAM frames per connection.

Standard load testing tools like k6 and JMeter cannot simulate this attack vector because they use standard HTTP client libraries that do not expose raw frame-level control. An authorized IP stresser with protocol-level capabilities is required.

Mitigation strategies

• Update your software — ensure Nginx, Apache, HAProxy, and all proxies are patched.
• Limit RST_STREAM rate per connection — configure your reverse proxy to close connections that send excessive RST_STREAM frames (e.g., Nginx: http2_max_concurrent_streams 128).
• Use a DDoS mitigation service — Cloudflare, AWS Shield, Akamai Prolexic all have Rapid Reset-specific mitigations.
• Monitor HTTP/2 frame metrics — alert on unusual ratios of RST_STREAM to DATA frames.

Also consider the interaction with TLS fingerprint spoofing — an attacker combining Rapid Reset with realistic browser TLS signatures is much harder to detect.