Application Security

HTTP/2 Rapid Reset: The Largest DDoS Attacks in Internet History

CVE-2023-44487 exploits a design flaw in HTTP/2 to amplify DDoS attacks, enabling record-breaking attacks peaking at 398 million requests per second.

Nayan Dey
Engineering Lead
5 min read

On October 10, 2023, Google, Cloudflare, and Amazon Web Services jointly disclosed CVE-2023-44487, a vulnerability in the HTTP/2 protocol that had been exploited since August 2023 to launch the largest distributed denial-of-service (DDoS) attacks ever recorded. Google observed attacks peaking at 398 million requests per second—7.5 times larger than the previous record.

The Protocol Flaw

HTTP/2, standardized in 2015, introduced stream multiplexing—the ability to send multiple requests over a single TCP connection simultaneously. Each request opens a "stream" that the server processes independently. HTTP/2 also includes a RST_STREAM frame that allows either side to cancel a stream without tearing down the entire connection.

The Rapid Reset attack exploits the interaction between these features:

  1. The attacker opens a new HTTP/2 stream by sending a HEADERS frame (initiating a request)
  2. Immediately after, the attacker sends a RST_STREAM frame canceling that same stream
  3. The server begins processing the request but then receives the cancellation
  4. The attacker repeats this at high speed—open, cancel, open, cancel

The key insight is that the server does meaningful work processing each request before the cancellation arrives. Meanwhile, the client's cost for each request-cancel pair is minimal. This creates an asymmetric amplification: the attacker spends a few bytes per request, while the server allocates memory, performs lookups, and begins generating responses.

Because the attacker immediately resets each stream, HTTP/2's built-in concurrency limits (the SETTINGS_MAX_CONCURRENT_STREAMS parameter) are ineffective. The canceled streams don't count toward the concurrent stream limit, so the attacker can open new ones indefinitely.

Attack Scale

The numbers were staggering:

  • Google: Mitigated attacks peaking at 398 million requests per second
  • Cloudflare: Blocked attacks reaching 201 million requests per second
  • AWS: Mitigated attacks at similar scale

To put this in perspective, Google noted that the peak attack generated more requests in two minutes than the total number of article views Wikipedia reported for the entire month of September 2023.

The attacks were also notable for their efficiency. Traditional volumetric DDoS attacks require massive botnets to generate enough traffic. Rapid Reset attacks achieved record-breaking request rates with relatively modest botnets—Google estimated the attacks originated from roughly 20,000 machines, a small number by botnet standards.

Who Was Affected

The vulnerability affects any HTTP/2 implementation. That means virtually every web server, load balancer, and CDN on the internet was potentially vulnerable:

  • Nginx: Required configuration changes to mitigate
  • Apache: Updated mod_http2
  • Envoy proxy: Released patches
  • HAProxy: Updated HTTP/2 handling
  • Go net/http: Released Go 1.21.3 with fixes
  • Node.js: Released patches for the built-in HTTP/2 module
  • .NET (Kestrel): Microsoft released patches

The protocol-level nature of the flaw meant that every HTTP/2 implementation had to be assessed and potentially patched independently.

Mitigations

The fix isn't simple because there's no single "correct" behavior defined in the HTTP/2 specification for handling rapid stream resets. Implementations took different approaches:

Rate limiting RST_STREAM frames. Servers can track how many RST_STREAM frames a client sends and close the connection if the rate exceeds a threshold.

Accounting for canceled work. Even though the client cancels the stream, the server can track the resources consumed by canceled requests and count them toward the client's resource limits.

Connection-level limits. Some implementations added limits on the total number of streams (including canceled ones) that a client can open within a time window.

Delayed resource allocation. Some servers modified their handling to defer expensive operations until after a brief window, giving RST_STREAM frames time to arrive before work begins.

A Protocol Design Issue

CVE-2023-44487 is fundamentally a protocol design issue rather than an implementation bug. The HTTP/2 specification allows the behavior that the attack exploits. The spec's authors didn't anticipate that the combination of cheap stream opening and immediate cancellation could be weaponized at scale.

This raises uncomfortable questions about other protocol-level assumptions. HTTP/3 (based on QUIC) has similar multiplexing capabilities—have its designers accounted for analogous attacks? What about other multiplexing protocols?

The incident also highlighted the challenge of coordinating responses to protocol-level vulnerabilities. Unlike a vulnerability in a specific software package, a protocol flaw requires every implementation to patch independently, often with different approaches.

Impact on HTTP/2 Adoption

Despite the severity, CVE-2023-44487 is unlikely to slow HTTP/2 adoption. The protocol's performance benefits are substantial, and the mitigations are effective once applied. However, the incident serves as a reminder that protocol complexity creates attack surface.

Organizations should ensure their HTTP/2 implementations are updated, test their DDoS mitigation capabilities, and consider whether their rate limiting accounts for the Rapid Reset pattern.

How Safeguard.sh Helps

Safeguard.sh tracks vulnerabilities across your entire stack, including web servers, load balancers, and proxy infrastructure. When protocol-level vulnerabilities like CVE-2023-44487 are disclosed, our platform identifies every affected component in your environment—from the Nginx instances in your Kubernetes clusters to the HTTP/2 libraries in your application code. Safeguard.sh's SBOM analysis ensures that protocol-level vulnerabilities don't get lost in the noise of application-layer scanning, and our remediation tracking helps you verify that every affected component is patched.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.