The internet's infrastructure rests on layers of protocols designed for efficiency and speed. HTTP/2, introduced in 2015, revolutionized web communication by introducing stream multiplexing—a feature that allows multiple requests and responses to travel simultaneously over a single TCP connection. While this dramatically improved performance, it also introduced unforeseen vulnerabilities that attackers have increasingly exploited.
The HTTP/2 Rapid Reset attack, designated CVE-2023-44487 and colloquially dubbed the "HTTP/2 bomb" or "compression bomb," exploits a specific flaw in how servers handle stream resets within the protocol's frame structure. By sending rapid streams followed by immediate reset frames, attackers can overwhelm servers with thousands of open streams that consume memory and CPU resources without completing any meaningful work. This technique requires minimal bandwidth and computing power on the attacker's end while causing disproportionate strain on targeted infrastructure.
Unlike traditional denial-of-service attacks that rely on volumetric flood, Rapid Reset is algorithmic. It leverages the HTTP/2 specification itself as a weapon, turning the protocol's efficiency mechanisms against it. The attack is not theoretical; since its public disclosure in September 2023, security teams worldwide have witnessed a sharp increase in targeted incidents, particularly affecting organizations with large-scale web infrastructures.
This article unpacks how the vulnerability works, why distributed organizations are at heightened risk, and what defensive measures can be implemented to protect critical services in healthcare, telecommunications, and other high-impact sectors.
How the Attack Works: Exploiting HTTP/2 Protocol Mechanics
To understand Rapid Reset, one must first grasp the fundamentals of HTTP/2's stream-based architecture. In HTTP/2, multiple streams can be multiplexed over a single TCP connection. Each stream is identified by a numeric identifier and supports bidirectional communication through frames—small, structured messages that carry headers, data, or control information.
The vulnerability lies in the interaction between two frame types: DATA frames and RST_STREAM frames. An attacker begins by opening a new stream with a single HEADERS frame, then rapidly sends numerous DATA frames followed immediately by RST_STREAM frames that signal the stream should be terminated. Because the HTTP/2 specification requires servers to allocate resources for each new stream before determining whether it should be accepted, the attacker can trigger memory allocation and CPU processing cycles for streams that never complete any actual work.
This technique is particularly dangerous because it operates within the bounds of the HTTP/2 specification. The protocol expects clients to eventually close streams, but Rapid Reset exploits a window between stream initiation and completion where servers must maintain state. When attackers send RST_STREAM frames requesting that servers immediately release the associated resources, those resources have not yet been fully allocated or processed. Before the server can complete the release operation, the attacker opens the next stream in the sequence. By maintaining thousands of such streams simultaneously—often through connection reuse—the attacker can exhaust server memory, CPU, and connection table capacity.
The attack complexity is extremely low. A basic script using tools like h2spec or custom Python implementations can generate thousands of rapid-reset frames per second from a single machine. More sophisticated variants employ distributed botnets to scale the attack further, but unlike volumetric DDoS, even a single threat actor with modest resources can cause significant disruption to poorly protected servers.
According to Cloudflare's research, the HTTP/2 Rapid Reset attack is capable of causing service degradation at rates as low as 15 requests per second against unpatched servers. This efficiency makes it an attractive option for attackers seeking to maximize impact while minimizing infrastructure investment.
Why Distributed Organizations Are Prime Targets
Organizations with large, distributed web footprints face disproportionate risk from HTTP/2 Rapid Reset for several interconnected reasons. First, their infrastructure typically relies heavily on HTTP/2's efficiency features to handle high concurrency and maintain performance across globally distributed endpoints. CDN networks, API gateways, microservices architectures, and cloud load balancers all depend on stream multiplexing to maximize throughput.
The scale amplifies the vulnerability. When an organization operates thousands of servers across multiple regions, attackers can target specific entry points where HTTP/2 termination occurs—often at edge CDN nodes or API gateways. Even if only a subset of servers is vulnerable, the attacker can cause cascading failures that propagate through interconnected systems.
Healthcare organizations exemplify this risk profile. Modern electronic health record (EHR) systems, telemedicine platforms, patient portals, and lab result interfaces all depend on web-based APIs that handle high-concurrency traffic patterns. During an attack, these systems may become unresponsive, potentially disrupting time-sensitive patient care operations. A spokesperson for a major healthcare provider confirmed to Dark Reading that their systems experienced significant latency spikes and intermittent outages during recent Rapid Reset attacks, prompting emergency security reviews across their entire application portfolio.
Telecommunications providers face similar challenges. As the backbone of global internet connectivity, telcos operate vast networks of DNS resolvers, authentication servers, session border controllers, and AAA (Authentication, Authorization, Accounting) platforms—all of which rely on HTTP/2 for high-performance communication between network elements. Several tier-1 providers reported to Dark Reading that they observed attack traffic exceeding 50,000 RST_STREAM frames per second during peak attacks, requiring immediate throttling measures and emergency patch deployment across their infrastructure.
The distributed nature of these organizations means they often have hundreds or thousands of HTTP/2 endpoints, each representing a potential vulnerability surface. In many cases, organizations deploy HTTP/2 support across their entire infrastructure without thorough inventory of which services actually require it, leading to inconsistent security configurations and delayed response times when attacks occur.
Detection and Mitigation Strategies
Defending against HTTP/2 Rapid Reset requires a layered approach that addresses the vulnerability at multiple protocol layers. The first and most critical step remains patching. Major web server software—including nginx, Apache HTTP Server, Microsoft IIS, and HAProxy—released patches shortly after the vulnerability's disclosure. These patches implement rate limiting on stream creation, frame rate thresholds, and more aggressive stream termination policies.
For organizations running custom or legacy HTTP/2 implementations, server-side configuration changes can provide interim protection. Most modern servers support settings that limit the maximum number of concurrent streams per connection or enforce minimum idle time before stream termination. AWS's security blog details how they configured their load balancers to reject clients exceeding a threshold of stream resets within a specific time window.
Cloud-native protections offer another layer of defense. Content delivery networks like Cloudflare, Akamai, and AWS Shield automatically detect Rapid Reset patterns and apply mitigation rules at the edge—often before traffic reaches origin servers. These services use machine learning models trained on HTTP/2 frame patterns to distinguish between legitimate high-concurrency traffic and malicious rapid-reset behavior.
Network-level defenses include deploying firewalls or DDoS mitigation appliances that inspect HTTP/2 frames and flag abnormal patterns. These systems can operate in transparent mode, dropping malicious traffic without disrupting legitimate connections. Some organizations also implement connection-level rate limiting at their perimeter firewalls, though this must be carefully tuned to avoid impacting legitimate high-traffic users.
For extreme cases where immediate threat mitigation is required, temporarily disabling HTTP/2 support can be an effective—albeit drastic—measure. While this reintroduces the performance challenges that HTTP/2 was designed to solve, it eliminates the attack surface entirely. Organizations should view this as a last-resort fallback rather than a long-term solution.
Long-Term Lessons for Web Infrastructure Security
The HTTP/2 Rapid Reset vulnerability underscores a broader challenge in internet infrastructure security: the inherent tension between performance optimization and security resilience. As protocols evolve to meet demand for speed and efficiency, they often introduce new attack surfaces that were not anticipated during original design.
This incident should serve as a wake-up call for security teams to conduct thorough protocol inventories across their infrastructure. Understanding which services actually require HTTP/2—and whether HTTP/3 might be a more secure alternative—is essential. HTTP/3, built on the QUIC transport protocol, addresses many of HTTP/2's security shortcomings by encrypting header information and implementing more robust stream management.
Organizations should also invest in observability infrastructure capable of monitoring HTTP/2 frame-level activity. Traditional network monitoring tools often cannot inspect encrypted HTTP/2 traffic in sufficient detail to detect Rapid Reset attacks. Solutions that integrate with application-level observability stacks or provide TLS decryption capabilities can offer the visibility needed for early detection.
Finally, the vulnerability highlights the importance of coordinated incident response. When attacks target widely deployed infrastructure components, individual organization resilience depends on collective defense capabilities. Sharing threat intelligence, attack signatures, and mitigation playbooks across industries—particularly among healthcare providers, telcos, and cloud operators—enables faster response times and reduces the overall attack surface.
As the internet's infrastructure continues to evolve, understanding how protocol-level vulnerabilities translate into operational impact remains a critical skill for security professionals, leveraging Cyber Threat Intelligence to stay ahead of evolving threats. HTTP/2 Rapid Reset is not an isolated incident; it is a symptom of the complex trade-offs inherent in building secure, performant web services at global scale.