Cloudflare’s H1 2026 DDoS Threat Report counted 935 network-layer DDoS attacks exceeding 1 terabit per second in the first six months of the year. That’s not a typo for a once-rare event category. It’s an average of more than five per day, and the jump between Q1 and Q2 alone was 519%. For most of DDoS mitigation’s history, a 1 Tbps attack was newsworthy on its own. In 2026 it’s Tuesday.
The Numbers That Matter Beyond the Headline
Across the whole first half of the year, Cloudflare mitigated roughly 5,343 network-layer attacks per hour, adding up to 23.2 million network-layer attacks and 29.64 trillion HTTP DDoS requests. The composition of those attacks shifted too: DNS-based attacks now make up 34.3% of network-layer activity, and DNS Floods specifically climbed from 25.7% to 40.0% of that category quarter over quarter. CLDAP Floods, a reflection technique that abuses misconfigured directory servers, surged 580% to become the third-largest attack vector.
That DNS shift is the detail most coverage of this report glosses over in favor of the bigger, more quotable 1 Tbps number. A DNS flood doesn’t need to out-muscle your server directly; it needs to overwhelm the resolver path your visitors depend on to find your site at all. A host that only advertises raw network capacity without saying anything about DNS-layer protection is answering a question nobody asked while skipping the one that increasingly matters.
Geopolitics Is Now a Targeting Signal, Not Just Context
Media and Publishing remained the single most-targeted industry, accounting for 14.2% of HTTP DDoS requests, driven by coverage volume around Iran, Ukraine, and the World Cup. Turkey moved into the third most-attacked country following NATO’s July summit, and the Government sector jumped from the 29th to the 9th most-targeted sector, the single largest sector movement Cloudflare recorded all year. None of that is coincidental. Attack volume against a sector or region now tracks news-cycle events almost in real time. A business’s DDoS exposure isn’t fixed. It moves with whatever’s happening in the news that a company, its clients, or its industry happens to be adjacent to.
The exposure isn’t limited to obvious targets like news outlets and government contractors, either. An e-commerce store that sells World Cup merchandise, a nonprofit connected to Ukraine relief, or a B2B vendor with government clients can all see attack volume spike for reasons that have nothing to do with anything they did.
What This Actually Means When Picking a Host
Most “how to choose DDoS protection” content treats the decision as a single yes/no checkbox: does the host offer DDoS protection or not. Cloudflare’s own data argues against that framing. The real questions are narrower and more specific:
| Question to ask a host | Why it matters given H1 2026 data |
|---|---|
| Is DNS-layer protection included, or only network-layer? | DNS Floods are now the single largest attack vector at 40% of network-layer activity |
| What’s the largest attack size the plan is rated to absorb? | 935 attacks exceeded 1 Tbps this half; a plan rated for old, smaller thresholds may not hold |
| Is mitigation automatic, or does it require a support ticket during an active attack? | Attacks are increasingly short-burst; a manual response process can be too slow to matter |
| Does protection scale with traffic spikes tied to news events, not just steady growth? | Targeting now correlates with news cycles, not just a company’s own size or visibility |
A host’s marketing page rarely answers all four of these on its own, which is exactly why it’s worth asking directly rather than assuming “DDoS protection included” covers the same thing everywhere. AllCloudHost’s own service level guarantees page is a reasonable model for what that kind of specificity should look like: what’s actually promised, not just gestured at.
Why CLDAP Floods Are the Vector Worth Learning About
CLDAP (Connectionless LDAP) reflection isn’t new as a technique, but its 580% surge this half makes it worth explaining in plain terms, since it doesn’t get the same press coverage DNS floods do. An attacker sends a small request to a misconfigured, publicly reachable directory server, spoofing the source address so the (much larger) response gets sent to the intended target instead of back to the attacker. The amplification factor can be enormous, meaning a modest amount of attacker bandwidth turns into a disproportionately large flood hitting the victim. None of this requires the victim to have done anything wrong. The exposed directory servers being abused typically belong to unrelated third parties, which is part of why this category of attack is hard to defend against with anything less than infrastructure built to absorb and filter volume at the network edge, rather than at the level of an individual server.
The Botnet Behind Why 1 Tbps Stopped Being Rare
Cloudflare’s H1 2026 report doesn’t exist in isolation. It follows a run of record-setting single attacks tied to one botnet, Aisuru (also tracked as Kimwolf), that explains a lot of why “over 1 Tbps” went from newsworthy to a five-times-a-day occurrence. In October 2025, the botnet set a record at roughly 29.7 Tbps in a brief burst against a dedicated measurement server, more a capability demonstration than an attack on a live target. By December 19, 2025, the same botnet family broke its own record again with a 31.4 Tbps attack Cloudflare named “The Night Before Christmas,” a campaign that also drove HTTP request rates cited above 200 million per second. Neither record attack sustained for long.
What makes Aisuru relevant to the broader 935-attack count, rather than just a headline-grabbing outlier, is what it’s built from: an estimated 1 to 4 million compromised consumer devices worldwide, heavily weighted toward things like Android TV boxes and other always-on home electronics running outdated, unpatched firmware. Each individual device contributes a small, almost unnoticeable fraction of a gigabit. Multiplied across a few million of them simultaneously, those fractions add up to a multi-terabit flood within seconds. This device composition is also why these attacks tend to be short and extremely intense rather than sustained for hours: coordinating millions of consumer devices in a tight burst is easier to sustain briefly than to hold indefinitely, and a short, massive spike is often enough to overwhelm infrastructure that wasn’t built to absorb a sudden peak, even if it could have handled sustained elevated traffic over a longer window.
For a hosting customer, the practical implication is that “average traffic capacity” is close to the wrong metric to ask about entirely. A network that comfortably handles steady, predictable load can still go down against a 30-second spike it was never provisioned to absorb, which is exactly the profile Aisuru-style attacks are optimized to produce.
What a Site Owner Can Still Control
None of the infrastructure-level detail above is something an individual site owner configures directly, but a few things on the application side still matter regardless of how strong the underlying network protection is. Setting a reasonable DNS TTL (time-to-live) rather than an unusually short one avoids adding unnecessary resolver load during a DNS-flood-style event, since a very low TTL forces resolvers to re-query far more often than a typical visitor pattern requires. Rate limiting at the application layer (capping how many requests a single IP can make to a login page or search form in a short window) won’t stop a multi-terabit network flood, but it does blunt the smaller, more common application-layer DDoS attempts that ride in alongside larger campaigns and that raw network capacity alone doesn’t filter out. And keeping a status page or alternate communication channel (a social media account, a status subdomain hosted separately) ready in advance means customers have somewhere to check during downtime, rather than the business having no way to communicate at all while the main site is unreachable.
The Uncomfortable Part for Small Sites
It’s tempting to assume this data is only relevant to large media companies and government contractors, the sectors explicitly named as top targets. But the same report’s broader point, that targeting increasingly tracks news-adjacency rather than company size, cuts the other way for smaller businesses too. A small site doesn’t need to be the intended target to get caught in a reflection or amplification attack aimed at shared infrastructure it happens to sit on. Downtime during any DDoS event still means lost sales, support tickets, and time spent explaining to customers why the site was unreachable, regardless of whether the business itself was ever the actual target. Asking a host the four questions above costs nothing. Finding out the answers during an actual attack costs considerably more.