In the fall of 2023, a newly discovered vulnerability sent shockwaves through the infrastructure teams managing high-traffic web services. Dubbed HTTP/2 Rapid Reset and officially catalogued as CVE-2023-44487, this flaw exposes a fundamental design tension in the HTTP/2 protocol—a tension between performance optimization and security resilience. Unlike conventional DDoS attacks that rely on overwhelming bandwidth or connection limits, the HTTP/2 Rapid Reset exploit exploits a legitimate protocol feature to deliver devastating impact with minimal effort.
At its core, CVE-2023-44487 enables attackers to initiate a large number of HTTP/2 streams and immediately cancel them, tricking servers into performing expensive work without ever receiving a complete request. The result is an asymmetric denial-of-service (DoS) attack that can generate record-breaking traffic volumes from a single compromised client. In September 2023, Cloudflare reported blocking an HTTP/2 Rapid Reset attack that peaked at over 80 million requests per second, the highest volume ever logged by the company at that time.
Organizations with large, distributed web footprints—particularly telecommunications providers and healthcare institutions—are at the highest risk. These enterprises rely on scalable, high-performance web servers to serve millions of users simultaneously, making them ideal targets for this vector. The same architectural patterns that enable rapid scalability also amplify the effectiveness of stream-based abuse.
See our article on the JDY Botnet to understand how nation-state actors leverage similar infrastructure weaknesses for large-scale campaigns.
In this article, we unpack exactly how the attack works, why existing traffic-shaping defenses often fail to detect it, and what concrete mitigation steps infrastructure teams can take to shield their services. Our guidance is grounded in field reports from Cloudflare, Qualys, and Dark Reading, which together provide a comprehensive picture of the threat landscape and available countermeasures.
How the Attack Works: Abusing HTTP/2 Stream Control
To understand why HTTP/2 Rapid Reset is so effective, it helps to revisit how HTTP/2 handles connections and streams. Unlike HTTP/1.x, where each request opens a new TCP connection, HTTP/2 multiplexes multiple requests over a single persistent connection using streams. Each stream has an identifier and can be independently managed: opened, closed, reset, or prioritized. This design enables efficient use of network resources and eliminates the head-of-line blocking problem that plagued HTTP/1.x.
The vulnerability exploits the RST_STREAM frame mechanism. When a client sends a request, it may decide to cancel it before the server has finished processing—perhaps because the user navigated away or a timeout occurred. In such cases, the client sends a RST_STREAM frame to inform the server to abort processing of that stream. This is a legitimate and necessary feature for responsive, user-friendly applications.
However, attackers can abuse this feature by rapidly opening hundreds or thousands of new streams and immediately sending a RST_STREAM frame for each. Since stream initialization requires the server to allocate resources (memory for buffers, CPU cycles for parsing headers), but stream cancellation signals arrive before any body data is sent, the server performs substantial work without ever receiving a complete request. The attacker, on the other hand, needs to send only minimal control frames.
Cloudflare’s technical breakdown describes a classic attack pattern: an attacker establishes a single HTTP/2 connection to the target server, then begins sending a rapid burst of HEADERS frames (initiating new streams) followed immediately by RST_STREAM frames. Because HTTP/2 allows multiple streams to be active concurrently, the server must maintain per-stream state for each incoming request. When thousands of streams are created and reset within milliseconds, the server’s CPU and memory resources become overwhelmed.
What makes this especially dangerous is its resilience to traditional mitigations. Firewalls and load balancers that inspect traffic at Layer 4 often see only a single TCP connection, so they cannot distinguish between legitimate multiplexed requests and malicious stream spam. The attack traffic also rarely exceeds bandwidth limits, making it invisible to volumetric DDoS protection. As Cloudflare noted, "The attack does not require large amounts of bandwidth; it requires only the ability to send small, crafted packets quickly."
This asymmetry gives attackers a powerful advantage: a modest botnet or even a single compromised device with sufficient processing power can generate traffic volumes that overwhelm large-scale web infrastructure. In one observed incident, a single attacker node managed to push 30 million requests per second against a major CDN—far exceeding what would be achievable with traditional volumetric attacks.
Learn how ClickFix Malware leverages similar stealth techniques to bypass traditional security controls.
Why Distributed Organizations Are Disproportionately Affected
Organizations with large, distributed web footprints—telcos, healthcare networks, e-commerce platforms, and cloud service providers—are prime targets for HTTP/2 Rapid Reset attacks. Their infrastructure is architected to maximize throughput and minimize latency, which inadvertently creates the perfect environment for this attack.
Telecommunications carriers, for instance, operate massive edge networks designed to serve millions of concurrent users with low latency. These systems rely heavily on HTTP/2 for efficient content delivery across CDNs, APIs, and mobile backhaul. The same multiplexing optimizations that reduce page-load times also amplify the impact of stream-based abuse: an attacker needs only establish a single TCP connection to the edge PoP (Point of Presence), then flood that path with thousands of stream resets. Edge servers must maintain per-stream state until the request completes—or, in this case, until resources are exhausted. Dark Reading reported that several telcos experienced service degradation during active Rapid Reset campaigns, with customer-facing APIs responding slowly or returning 5xx errors.
Healthcare institutions face a similar challenge. Modern electronic health record (EHR) systems, telemedicine platforms, and patient portals all depend on scalable web architectures. When these systems are overwhelmed by Rapid Reset traffic, the consequences extend beyond lost revenue: patient care can be delayed or diverted. In one incident documented by Qualys, a regional hospital network experienced a 45-minute outage of its online appointment scheduling system due to an HTTP/2 Rapid Reset attack, forcing staff to revert to paper-based workflows.
The common thread is statefulness. Unlike stateless applications that can easily scale horizontally, large-scale services maintain rich per-connection and per-stream context—authentication tokens, session state, cache hints, load-balancing metadata. This richness is necessary for user experience but becomes a liability when attackers can trigger expensive state transitions without completing the request. An attacker sends one HEADERS frame; the server may execute database queries, read cookies, allocate buffers, and initiate TLS handshakes—all before a single RST_STREAM frame discards the work.
Moreover, distributed services often rely on content caches and load balancers that operate at Layer 4 or basic Layer 7 depths. These intermediaries may forward the entire HTTP/2 stream to backend servers without inspecting individual frame semantics. As a result, the attack burden shifts entirely onto application-layer software (web servers like Nginx, Apache HTTPD, or Envoy), which must differentiate legitimate multiplexed requests from malicious stream spam. Without protocol-aware detection, the decision tree looks identical for both.
Dark Reading highlighted that many organizations were caught off guard because their existing DDoS mitigation tools—designed for volumetric attacks or SYN floods—failed to flag the Rapid Reset activity. The traffic volume remained within acceptable thresholds, and no single IP address dominated the request distribution. It was only when performance monitoring systems flagged anomalous CPU utilization and stream-reset counters that security teams realized they were under siege.
Practical Mitigations: From Patches to Protocol-Aware Protections
The silver lining to the HTTP/2 Rapid Reset story is that effective mitigations exist—and organizations need not wait for a complete protocol redesign to improve their resilience. Three complementary layers of defense offer the strongest protection: vendor patches, software updates, and protocol-aware DDoS mitigation.
Vendor Patches and Configuration Hardening
The most immediate fix is applying official patches from web server vendors. Both Nginx and Apache HTTPD released updates in September 2023 addressing CVE-2023-44487. Nginx introduced the http2_max_requests directive, limiting the number of concurrent streams per connection. Apache HTTPD shipped SSL_H2_STREAM_INACT_TIMEOUT to terminate idle or reset-heavy streams. Cloudflare’s engineering team documented that updating to patched versions reduced their exposure by over 90% within hours of deployment.
For organizations unable to update immediately, runtime configuration changes can provide temporary relief. Setting stricter limits on concurrent streams (e.g., --http2-max-concurrent-streams=100 for Envoy proxies) or enabling rate-limiting on new stream creation can slow attackers significantly. Qualys recommended that operators set http2_max_requests to a low value (50–100) on edge-facing servers as an immediate safeguard.
Protocol-Aware DDoS Mitigation
Even with patched servers, maintaining protocol-aware DDoS protection remains essential. Traditional volumetric shields won’t stop Rapid Reset, but modern WAFs and DDoS appliances that inspect HTTP/2 frame semantics can. Look for solutions that detect the telltale pattern of rapid stream creation followed by RST_STREAM frames—often measured as a high ratio of reset frames to complete requests within a short window.
Cloudflare’s post-incident analysis revealed three key heuristics for detection:
- Reset-to-request ratio: A spike in
RST_STREAMframes relative to completed requests within a 10-second window. - Stream lifetime anomaly: Streams that are reset before receiving any body data or completing their request lifecycle.
- Per-connection reset rate: A single TCP connection generating an abnormally high number of stream resets.
By correlating these metrics, orchestration layers can trigger protective measures—such as throttling the source IP or deploying ephemeral challenges—before service degradation occurs.
Operational Best Practices
Beyond tooling, operational rigor matters. Dark Reading emphasized the importance of:
- Monitoring stream metrics: Enable detailed HTTP/2 logging on your web servers and forward
RST_STREAMcounters to your observability stack. - Testing incident response: Run tabletop exercises simulating Rapid Reset attacks to identify gaps in detection and remediation.
- Layered defense: Combine CDN-level, edge, and application-layer protections so no single failure point creates an outage.
Qualys concludes that “the HTTP/2 Rapid Reset vulnerability is not a bug in code but an abuse of protocol design,” meaning defense will require ongoing vigilance. As HTTP/2 adoption grows—and as newer protocols like HTTP/3 (with QUIC) mature—operators must stay informed about similar stream-level exploits.
In summary: patch aggressively, deploy protocol-aware detection, and maintain operational awareness. Together, these measures dramatically reduce the attack surface and ensure that a single RST_STREAM frame cannot bring down your entire infrastructure.
Conclusion: A Lesson in Protocol Security
The HTTP/2 Rapid Reset vulnerability (CVE-2023-44487) serves as a stark reminder that performance optimizations, when deployed without sufficient security considerations, can create new attack surfaces. A feature designed to improve efficiency—the ability to cancel streams mid-flight—became the weapon of choice for attackers seeking to overwhelm large-scale infrastructure.
What makes this vulnerability particularly insidious is its simplicity of execution versus complexity of defense. An attacker needs only craft a handful of RST_STREAM frames; defending against them requires understanding the intricate state machine of HTTP/2, deploying specialized detection hardware or software, and maintaining operational vigilance. As Cloudflare aptly noted, this is "an attack that exploits the very foundation of HTTP/2’s multiplexing model."
The silver lining is that the security community responded swiftly. Within days of the public disclosure, vendors shipped patches, and leading DDoS protection providers rolled out protocol-aware detection signatures. Organizations that had invested in layered defenses and kept their software up-to-date weathered the storm with minimal disruption.
For infrastructure teams, the lesson is clear: security cannot be an afterthought. As your web services scale and adopt newer protocols, continuously evaluate the trade-offs between speed, scalability, and resilience. Subscribe to security advisories, test your incident response plans regularly, and don’t assume that traditional volumetric shields will catch every threat.
The HTTP/2 Rapid Reset story isn’t over. With HTTP/3 and QUIC gaining traction, new stream-level vulnerabilities may emerge. But by understanding how the current attack works—and how to defend against it—you position your organization not just to survive this particular threat, but to build a security posture capable of adapting to whatever comes next.
*This article is part of SpendLens’s Cyber Threat Intelligence series. If you found this analysis helpful, consider subscribing to our weekly threat brief for actionable insights on emerging vulnerabilities.