HTTP/2 Rapid Reset: Record DDoS Flaw in HTTP/2 Servers

What to do

1. Inventory every component that terminates HTTP/2 from untrusted clients: reverse proxies, ingress controllers, app servers, language runtimes.
2. Upgrade each to a release with a rapid-reset mitigation (for example nghttp2 1.57.0+, Node.js 18.18.2+/20.8.1+, Tomcat 10.1.14+, NGINX Plus R29p1/R30p1).
3. On NGINX keep keepalive_requests at its default of 1000 and http2_max_concurrent_streams at 128, and add limit_conn and limit_req.
4. Put internet-facing HTTP/2 endpoints behind a DDoS-capable CDN or cloud load balancer where practical.
5. If you cannot patch an exposed service, consider disabling HTTP/2 on it until you can.

How to check if you are affected or compromised

• Check versions: `nginx -v`, `node -v`, `go version`, and your Tomcat release notes or `version.sh`.
• Look for connections carrying very high counts of RST_STREAM frames or requests that are canceled before a response.
• Watch for sudden CPU or memory spikes on HTTP/2 frontends without matching completed-request volume; Tomcat typically shows OutOfMemoryError.

What happened#

On October 10, 2023, Google, Cloudflare, AWS and others jointly disclosed a denial-of-service technique against the HTTP/2 protocol itself, tracked as CVE-2023-44487 and nicknamed "Rapid Reset." HTTP/2 lets a client run many requests (streams) over one TCP connection, capped by a concurrent-stream limit. An attacker sends a request and immediately cancels it with a RST_STREAM frame. The cancellation frees the slot, so the client can keep opening and canceling streams without limit, while the server still pays for each one (allocating stream state, decoding headers, routing). Google described the cost asymmetry and two variants, including one that batches cancellations to dodge rate limits.

This was not theoretical. NVD notes exploitation in the wild from August through October 2023 and scores it CVSS 7.5 (availability only). Google saw a peak above 398 million requests per second; Cloudflare saw just over 201 million from a botnet of about 20,000 machines, first noticed on August 25. CISA added the CVE to the KEV catalog on October 10, 2023, and it remains listed as of this writing.

Who is affected#

Because the weakness is in protocol behavior, almost every server-side HTTP/2 implementation needed a change. Examples of fixed releases: nghttp2 1.57.0 (mitigated by default), Node.js 18.18.2 and 20.8.1, Apache Tomcat 10.1.14 (10.1.0-M1 to 10.1.13 affected, typically failing with OutOfMemoryError), and NGINX Plus R29p1/R30p1. Go 1.21.3 and 1.20.10 shipped the same day with a net/http security fix. Clients and HTTP/1.1-only services are not the target; Google said HTTP/3 is not believed vulnerable to these methods.

Do you really need to act?#

The impact is outage, not data theft or code execution. The question is who terminates your HTTP/2 connections. If public traffic first hits a large CDN or cloud load balancer, that provider was mitigating before disclosure: AWS said its infrastructure already had protections and added more, and only asked customers running their own HTTP/2 servers to check with vendors. Google said its load balancing stopped the attacks at the edge.

If instead your own NGINX, Tomcat, Node.js or Go service speaks HTTP/2 directly to the internet, you are the edge, and an unpatched build can be taken down by a modest botnet. Three years on, the remaining risk is mostly in forgotten appliances, old container images and embedded servers that never got the update. CISA advised patching and applying vendor configuration mitigations.

What to do now#

1. List everything that terminates HTTP/2 from untrusted clients: ingress controllers, reverse proxies, app servers, runtimes.
2. Upgrade each to a mitigated release (check with nginx -v, node -v, go version, Tomcat version.sh).
3. On NGINX, F5 advises keeping keepalive_requests at 1000 and http2_max_concurrent_streams at 128, plus limit_conn and limit_req.
4. Where practical, front public HTTP/2 endpoints with a DDoS-capable CDN or load balancer, which Cloudflare called the best defense.
5. If an exposed service cannot be patched, disable HTTP/2 on it until it can.

How to tell if you were hit#

This attack leaves no persistent compromise; the symptom is degraded service. Signs include connections with large numbers of canceled streams, CPU or memory spikes on HTTP/2 frontends without matching completed requests, and bursts of 502 errors from proxies. Google's suggested heuristic flags connections with more than 100 requests where over half were canceled.

Timeline#

• Aug 25, 2023 — Cloudflare first observes Rapid Reset attacks; Google's largest attacks peak in August.
• Sep 14, 2023 — Issue reported to the Apache Tomcat security team.
• Oct 10, 2023 — Coordinated disclosure; nghttp2 1.57.0, Tomcat 10.1.14 and Go 1.21.3/1.20.10 released; CISA alert and KEV listing.
• Oct 13, 2023 — Node.js 18.18.2 and 20.8.1 security releases.
• Oct 21, 2026 — Still listed in CISA KEV; brief updated.

Vulnerability records

• CVE-2023-44487 · KEV 2023-10-10 · The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the…

Sources

Original sources first: vendor and project advisories, CVE and government records, the discoverers’ write-ups. Every claim above links to one of these. See how the Security Desk works.

Original and primary sources

1. NVD — CVE-2023-44487 nvd.nist.gov
2. CISA — HTTP/2 Rapid Reset Vulnerability, CVE-2023-44487 cisa.gov
3. CISA — Known Exploited Vulnerabilities Catalog cisa.gov
4. Google Cloud — How it works: The novel HTTP/2 'Rapid Reset' DDoS attack cloud.google.com
5. Cloudflare — HTTP/2 Rapid Reset: deconstructing the record-breaking attack blog.cloudflare.com
6. AWS — Security Bulletin AWS-2023-011 aws.amazon.com
7. nghttp2 — GHSA-vx74-f528-fxqg github.com
8. Node.js — October 2023 security releases nodejs.org
9. Apache Tomcat — Tomcat 10 security fixes tomcat.apache.org
10. F5 — HTTP/2 Rapid Reset Attack Impacting F5 NGINX Products f5.com
11. Go — Release history go.dev