HTTP/2 Rapid Reset: The Attack That Broke the Internet in 2023.

On October 10, 2023, Cloudflare, Google, and Amazon published a joint disclosure: in August of that year they had recorded DDoS attacks several times more powerful than any previous record. Google absorbed a peak of 398 million requests per second. Cloudflare — 201 million. Amazon — 155 million. Cloudflare’s previous record had been 71 million rps, set in February 2023. All three attacks were carried out through a single vulnerability in the HTTP/2 protocol.

CVE-2023-44487. CVSS 7.5 High. The attack was named Rapid Reset.

WHAT IS HTTP/2 AND WHY DOES IT USE STREAMS

HTTP/1.1 worked simply: one request, one response, sequentially. To load a page with ten images a browser opened up to 6 parallel connections per domain — the specification allows no more. The remaining requests queued up. This is slow.

HTTP/2 solved the problem with multiplexing: multiple requests and responses travel simultaneously inside a single TCP connection. Each request is a separate stream. The browser opens a stream for HTML, then streams for CSS, JS, images — all in parallel, one connection.

To cancel a stream in HTTP/2 there is a dedicated frame — RST_STREAM. If the browser decides not to load an image, it sends RST_STREAM and the stream closes. This is a normal part of the protocol.

And this is exactly where the vulnerability hides.

MECHANICS OF THE ATTACK

The problem is that RST_STREAM is a unilateral operation. The client sends the frame and immediately considers the stream closed. The server is required to begin processing the request before receiving the cancellation — according to the HTTP/2 specification it cannot refuse the work in advance.

The attacker exploits this as follows:

Step 1. Opens an HTTP/2 connection to the server.

Step 2. Sends a request — opens a stream.

Step 3. Immediately, without waiting for a response, sends RST_STREAM — cancels the stream.

Step 4. Returns to step 2. Thousands of times per second. In one TCP connection.

The server receives a flood of requests it must begin processing, then a flood of cancellations, then requests again. CPU and memory are consumed creating and destroying processing contexts. Nothing is left for real users — the server is busy.

The cost to the attacker is minimal: one TCP connection, minimal traffic. A botnet of 20,000 machines created load that previously required a network of hundreds of thousands or millions of nodes — this is exactly how Cloudflare described the gap in their official blog.

WHY THIS IS NOT JUST A BUG IN NGINX

Rapid Reset is a vulnerability in the HTTP/2 protocol itself, not in any specific implementation. The attack affected nginx, Apache, Tomcat, .NET, Go, Node.js — everything that implements HTTP/2. Patches had to be released by everyone simultaneously.

Important nuance: the nginx developers officially stated that nginx with default settings is not vulnerable to Rapid Reset — the default keepalive_requests limit already restricts the number of requests per connection and reduces the attack’s effect. The patch in version 1.25.3 adds improved detection of misbehaving clients for cases where defaults have been changed. This is exactly why the official CHANGES wording reads: “improved detection of misbehaving clients when using HTTP/2.”

For nginx the vulnerability is closed in version 1.25.3, released on October 24, 2023. If you are running nginx older than this version with a non-default keepalive_requests and HTTP/2 enabled — the server is potentially vulnerable.

Check your version:

nginx -v

Check whether HTTP/2 is enabled in the config. Before nginx 1.25.0, HTTP/2 was enabled on the listen line; from nginx 1.25.0+ it uses a separate directive. This command catches both:

grep -r "http2" /etc/nginx/sites-enabled/

If you see listen 443 ssl http2 or http2 on — HTTP/2 is active.

HOW TO PROTECT YOURSELF

Step 1 — update nginx

The most important step. nginx 1.25.3 and later contain a patch with improved detection of misbehaving clients when using HTTP/2 — this is the exact wording in the official CHANGES. When the rapid reset pattern is detected the server closes the connection instead of continuing to process each cancelled transaction:

# Debian/Ubuntu
sudo apt update && sudo apt upgrade nginx

# RHEL/CentOS/Fedora
sudo dnf update nginx

# Verify after updating
nginx -v

Step 2 — limit the number of concurrent streams

The http2_max_concurrent_streams directive limits how many parallel streams a client can open in a single connection. The default is 128. For most sites 64 or even 32 is sufficient:

http {
    http2_max_concurrent_streams 64;
    ...
}

Fewer streams means less work during an attack. Chrome and Firefox support up to 100 concurrent streams per connection, but for a typical page load rarely use more than 20–30. A limit of 64 will not affect real users.

Step 3 — limit connections per IP

Rapid Reset is most effective with a large number of connections. limit_conn restricts how many simultaneous connections are accepted from a single IP:

http {
    limit_conn_zone $binary_remote_addr zone=addr:10m;

    server {
        limit_conn addr 10;
    }
}

One IP — no more than 10 simultaneous connections. A botnet continues to operate through different IPs, but the load from each connection is bounded.

Step 4 — Cloudflare as the first line of defense

Cloudflare blocked Rapid Reset attacks automatically in October 2023 — before the CVE was publicly disclosed. If the site sits behind Cloudflare with proxying enabled, the majority of the attack never reaches nginx at all.

Verify that Cloudflare is in proxy mode (orange cloud on DNS records), not just DNS. Without the proxy, Cloudflare does not filter traffic.

TYPICAL MISTAKES

Thinking that simply disabling HTTP/2 solves the problem. Technically yes — but HTTP/2 delivers real performance gains, and disabling it to protect against a vulnerability that is already patched makes no sense.

Updating nginx but not reloading it. After apt upgrade nginx a systemctl reload nginx is required — without it the process keeps running on the old code.

Not checking whether HTTP/2 is even enabled. Many sites run on HTTP/1.1 and are not vulnerable to this attack at all — check before changing the config.

CONCLUSION

HTTP/2 Rapid Reset is a rare case where a vulnerability affected not a specific product but a foundational internet protocol. A patch could not appear overnight — it was coordinated across Google, Cloudflare, Amazon, Microsoft, nginx, Apache, and dozens of others simultaneously.

You should be concerned if you are running nginx older than 1.25.3 with HTTP/2 enabled. Updating fully closes the vulnerability. Limiting http2_max_concurrent_streams and limit_conn adds an extra layer of protection that makes sense to configure regardless of version.

Cloudflare withstood 201 million requests per second. An unpatched nginx on a two-core VPS would not.