How a Flaw in the Internet’s Own Architecture Let Attackers Flood Cloudflare with 201 Million Requests Per Second
In October 2023, three of the largest technology companies in the world — Google, Amazon, and Cloudflare — simultaneously disclosed that they had spent the previous two months quietly defending against the largest distributed denial-of-service attack ever recorded.
The attack sent 201 million requests per second at Cloudflare’s network. Google saw 398 million. The numbers are almost meaningless without context, so here is some: at peak, this single attack was generating more internet traffic than the entire global internet does in a typical second.
Most of the businesses sitting behind Cloudflare never knew it happened.
This is the story of how a 20-year-old quirk in the internet’s own architecture was weaponised, why it was categorically different from previous attacks, and what it means for any business that relies on its website being available when clients come looking.
First: What is HTTP/2, and Why Does It Matter?
When you visit a website, your browser and the web server have a conversation. Your browser sends a request (“give me this page”), the server responds with the content, and the conversation ends. In the early days of the internet, each of those conversations required its own separate connection — like opening a new phone line for every question you asked.
HTTP/2, released in 2015, improved on this significantly. It introduced “multiplexing”: the ability to send many requests down a single connection simultaneously, like a motorway replacing a single-lane road. Pages loaded faster. Connections were reused. The internet became noticeably quicker for everyone.
HTTP/2 also introduced something called RST_STREAM — a cancellation signal. If your browser starts downloading something and then decides it doesn’t need it (because you have already navigated away, for example), it can send RST_STREAM to tell the server to stop. Polite, efficient, sensible.
That cancellation mechanism turned out to be the weapon.
The HTTP/2 Rapid Reset Attack (CVE-2023-44487)
The vulnerability is disarmingly simple in principle. Attackers discovered that they could open a stream on an HTTP/2 connection, immediately send RST_STREAM to cancel it, and then repeat this sequence at machine speed — thousands of times per second, per connection.
The problem is the timing. When a server receives a new stream request, it allocates resources to process it — memory, CPU cycles, queue space. When RST_STREAM arrives a fraction of a second later, the server releases those resources. But in the gap between the request and the cancellation, meaningful processing work has already happened.
By cycling through this pattern at extreme speed, attackers could force servers to do enormous amounts of processing work while giving them almost nothing useful to account for. The server’s resource counters never showed an obviously oversized queue — streams were being cancelled — but the CPU was burning through cycles handling the deluge. Standard DDoS rate-limiting, which counts concurrent open connections, was largely blind to what was happening.
The attack used a botnet of roughly 20,000 compromised machines — relatively modest by historical standards. What made it devastating was the leverage: each machine could sustain a rate of requests that far exceeded what a conventional DDoS would achieve with the same hardware, because HTTP/2’s multiplexing meant each connection could carry hundreds of simultaneous streams.
What Cloudflare Did About It
Cloudflare’s network detected anomalous HTTP/2 traffic patterns in August 2023 and began developing mitigations before the vulnerability was publicly known. By the time it was formally disclosed in October — as CVE-2023-44487 — Cloudflare had already deployed protections at the network edge.
The mitigation strategy involved detecting the characteristic RST_STREAM cycling pattern and terminating connections exhibiting it before the requests could saturate origin servers. Because Cloudflare operates at the edge — absorbing traffic before it reaches the infrastructure behind it — clients using Cloudflare’s WAF and DDoS protection experienced no disruption.
The businesses running behind Cloudflare had no idea the attack was happening. That invisibility is precisely the point.
For organisations running on unprotected shared hosting, or behind basic firewall rules that had never been tested against HTTP/2-layer attacks, the picture was very different. Several high-profile targets experienced significant downtime before patches could be applied to their web server software — NGINX, Apache, and virtually every HTTP/2 implementation required updates.
Why This Attack Is Different From What Came Before
Most DDoS attacks are blunt instruments: flood a server with so much traffic that it can’t respond to legitimate requests. They are noisy, expensive to sustain, and relatively straightforward to filter once detected.
The HTTP/2 Rapid Reset attack was architectural. It exploited a design decision in a protocol specification used by virtually every web server on the internet. There was no malicious code to block, no suspicious payload to inspect. The attack packets were indistinguishable from normal HTTP/2 traffic — they just arrived at an impossible rate.
This matters because it illustrates a principle that the security industry has understood for a long time but that is rarely communicated clearly to business owners: the most dangerous vulnerabilities are often not in software you can see or update. They are in the invisible infrastructure that carries your data.
Patching your WordPress plugins does not protect you from a protocol-layer attack. Renewing your SSL certificate does not help. What protects you is infrastructure that sits between the internet and your server, operated by people who are watching those patterns 24 hours a day and have the engineering capacity to respond faster than the attack can evolve.
What This Means for Your Business
If your website is running on shared hosting — even from a reputable provider — you are sharing infrastructure with hundreds or thousands of other businesses. When a large-scale attack targets that infrastructure, the collateral damage is indiscriminate.
If your website does not sit behind an enterprise-grade network proxy — something that absorbs and filters traffic before it reaches your hosting environment — you are exposed to the category of attack described above, and to the next variation that has not been publicly disclosed yet.
The HTTP/2 Rapid Reset attack was not the first of its kind and it will not be the last. The gap between disclosure and exploitation is shortening. The gap between disclosure and patching, for businesses relying on their hosting provider to handle it, is often measured in weeks.
Cloudflare clients had zero-day protection — not because Cloudflare is magic, but because operating at the scale they do means they see attack patterns earlier than anyone else and have the engineering depth to respond.
That protection is not reserved for enterprise corporations. It is available to any business that makes it a deliberate infrastructure decision rather than an afterthought.
Opyx Digital builds and manages web infrastructure for UK businesses. All sites are deployed behind Cloudflare’s enterprise network as standard, with WAF, DDoS mitigation, and bot management active from day one. If you want to understand what your current infrastructure can and cannot protect you against, book our £250 Infrastructure Audit.