HTTP/2 Rapid Reset (CVE-2023-44487): Protocol Semantics Weaponized

In late 2023, one of the largest distributed denial-of-service (DDoS) campaigns in Internet history leveraged a protocol-level weakness in HTTP/2. The vulnerability — CVE-2023-44487, commonly known as HTTP/2 Rapid Reset — did not rely on amplification or bandwidth saturation.

It exploited protocol logic.

Protocol Context: HTTP/1.1 vs HTTP/2 Multiplexing#

HTTP/2 introduced multiplexing, allowing multiple concurrent request streams over a single TCP connection.

In HTTP/1.1:

One request effectively blocks the next
Head-of-line blocking
Heavy reliance on multiple connections

In HTTP/2:

Multiple independent streams per connection
Framed messages
Improved performance and reduced latency

Figure 1: HTTP/1.1 and HTTP/2 request and response pattern (Courtesy of Google)

Figure 1. HTTP/1.1 and HTTP/2 request and response pattern (Courtesy of Google)

Multiplexing improved performance dramatically — but it changed server-side resource accounting.

Exploit Mechanism: RST_STREAM Abuse#

HTTP/2 allows a client to cancel a request stream using the RST_STREAM frame.

Normal stream lifecycle (simplified)#

Client sends HEADERS
Stream transitions idle → open
Client sends END_STREAM
Server processes request
Server returns response and stream completes

Rapid Reset behavior#

Client sends HEADERS
Client immediately sends RST_STREAM
Server begins processing work
Stream closes before response delivery
Client immediately opens another stream

Figure 2: HTTP/2 stream state transitions (Courtesy of Cloudflare)

Figure 2. HTTP/2 stream state transitions (Courtesy of Cloudflare)

The critical insight:

When a client cancels a stream, it instantly regains the ability to open another stream.

Because concurrency limits apply to active streams, rapidly closed streams allow attackers to avoid hitting thresholds while still forcing server work.

Operational Impact: Why This Scales#

This vulnerability was actively exploited between August and October 2023.

Targets included:

Google
AWS
Cloudflare

Reported peaks exceeded hundreds of millions of requests per second.

Unlike volumetric DDoS attacks, Rapid Reset:

Does not rely on bandwidth saturation
Exploits application-layer work and request parsing
Scales efficiently per TCP connection
Focuses on CPU and request handling exhaustion

Detection: What “Bad” Looks Like in Telemetry#

A public testing tool was released to identify vulnerable implementations. At a high level, detection attempts to measure whether a server:

allows rapid create/reset cycles without penalty,
continues processing work despite immediate resets, and
fails to terminate abusive connections.

1. Objective

Determine whether the service enforces effective controls against rapid create/reset stream behavior that can be weaponized for application-layer resource exhaustion.

2. Evidence

Command-line output enumerating vulnerable assets. — **Figure 3.** Command-line output enumerating vulnerable assets

Evidence Type: Tool Output (HTTP/2 rapid reset test)
Condition: Stream opened and immediately reset (RST_STREAM)
Expected Control Behavior:
  - Rate limit resets OR
  - Penalize excessive resets OR
  - Terminate abusive connections
Indicator of Exposure:
  - Sustained rapid create/reset cycles without throttling or termination

3. Interpretation

If the service allows continuous rapid creation and cancellation of streams without throttling, penalty, or connection termination, it is likely vulnerable (or functionally exposed) to Rapid Reset-style abuse.