Cloudflare logged 8,200 DDoS attacks an hour in Q3 2026

The renewal that lands in a bad quarter

A platform team running a public-facing estate of a few hundred services is three weeks from renewing its DDoS scrubbing contract, and the renewal deck is built on a single number: peak mitigation capacity. The vendor's slide shows terabits absorbed. The team's own incident log from the summer shows something different, a run of short outages on the checkout path that each cleared before anyone joined the bridge, and a support ticket that came back marked mitigated with no explanation of when mitigation started.

That mismatch is the quarter in miniature. Cloudflare's 26th DDoS Threat Report, covering July, August and September 2026 and produced by Cloudforce One, records 18.2 million network-layer attacks mitigated across its network in the quarter, which works out to roughly 8,226 an hour, about 197,400 a day, or one every 0.44 seconds. The same report puts 98% of those attacks under 1 Gbps.

A contract negotiated on the assumption that the threat is a giant flood is therefore aimed at the wrong tail of the distribution. The giant floods still exist, but they are rarer than they were in the second quarter, and the volume that actually reaches a mid-sized estate is small, frequent and brief. The buyer's problem is not whether the scrubbing centre can absorb a terabit. It is whether anything engages in the first ten seconds of a 400 Mbps burst.

Why the short burst is the harder problem

Cloudflare attributes the surge in short, low-bandwidth, high-count attacks to DDoS-for-hire booter services, and names computer software, gambling and casinos, and information technology as the industries most targeted by that pattern. The report's own framing is blunt about the consequence: 98% of attacks stayed under 1 Gbps, which it describes as more than enough to overwhelm a server or website.

The mechanism is arithmetic rather than sophistication. A 400 Mbps burst aimed at one host saturates its uplink long before it troubles a scrubbing centre with 500 Tbps of capacity, and if the burst lasts four minutes, a mitigation path that needs a human to confirm a threshold alert will miss most of it. Cloudflare's own pitch rests on this: it states that its systems detect and mitigate attacks without human intervention, and that most attacks end long before a human analyst could see the alert.

That is a vendor describing its own architecture, and a buyer should read it as a specification to test rather than a claim to accept. The question to put to any provider is the same one: at what point in the first ten seconds does traffic leave the normal path, and what triggers it. A provider that answers with capacity has not answered the question.

The other half of the quarter complicates the story rather than simplifying it. Hyper-volumetric attacks above 1 Tbps fell to 251 from 805 in the second quarter, which Cloudflare suggests may reflect law enforcement action against four major IoT botnets earlier in the year. Capacity still matters, because the same report records a 49.7-hour sustained Mirai-classified attack between 19 and 21 August and four days that month where mitigated Mirai traffic each cleared three petabytes.

The vector you filtered for last year is gone

The most useful number in the report for anyone maintaining a filter list is the CLDAP collapse. Connectionless Lightweight Directory Access Protocol floods, in which small queries with a forged victim address trick public domain controllers on UDP 389 into reflecting large responses at the target, had surged 580% quarter over quarter in the first half of 2026. In the third quarter they fell to 0.05% of attacks, a 99.5% drop.

Attackers did not stop reflecting. They moved to DNS amplification, up 215% to 3.43% of network-layer attacks, which exploits open DNS resolvers in the same pattern of small spoofed queries and large replies. Other UDP floods climbed from 14.06% to 31.31% of network-layer attacks, and the report explains why: UDP is connectionless, so a target that receives a packet checks for a listening application and responds, spending network and compute on the reply.

For the buyer, this is a maintenance finding rather than a procurement one. A rule set tuned to the first half of 2026 is tuned to a vector that has almost vanished, while the protocol-level exposure that replaced it is broader and less specific. The durable controls are the boring ones, closing open resolvers and rate-limiting UDP, and they belong in the same review as the contract because they decide how much of the flood ever reaches the scrubbing decision.

The report also records where the attacks landed. Media, Production and Publishing remained the most-attacked industry but at roughly a quarter of its second-quarter share, with Internet infrastructure rising from outside the top ten to sixth, and Consumer Services and Adult Entertainment entering at eighth and ninth. The United States retook the most-attacked position from China, Canada jumped from 16th to sixth and Israel moved seven places to tenth. A buyer in retail or telecommunications in Canada is now in a different risk band than the same buyer was in the spring.

What the vendor's own numbers do not settle

Cloudflare publishes its capacity as 500 Tbps across more than 330 cities, and describes that as 23 times larger than the biggest DDoS attack ever recorded. It also publishes a free DDoS Botnet Threat Feed for service providers, which it says more than 800 networks have signed up to. Both are useful facts about the vendor's position and neither is a fact about a specific estate's exposure.

The report does not break out how many of the 18.2 million mitigated attacks were aimed at paying customers, how quickly mitigation engaged on the short bursts, or what proportion of customers saw any attack at all. Those are the numbers a buyer would want, and they are unpublished. The honest reading is that the report describes the shape of the threat across a very large network, not the service level any one contract receives.

That distinction matters at renewal because the report is often quoted as if it were a benchmark. It is a description of what arrived at one network and how that network handled it. The buyer's own incident log, with timestamps for when an attack started and when traffic normalised, is the only evidence about their own time-to-mitigation, and it is the document to bring to the call.

The shortlist the buyer ends up with

Three weeks out, the platform team has narrowed the renewal to three shapes of answer rather than three logos: keep the scrubbing contract and add an always-on path, move the public edge to a provider that mitigates autonomously by default, or keep the contract and buy the protocol-level hygiene that stops most of the small floods before they arrive. The table below is the shortlist as the team wrote it, with the published facts that separate the options.

The capacity column is the one the incumbent leads on and the one that matters least this quarter. The time-to-mitigation column is the one nobody has published, which is why it is the question on the call rather than a row in the grid.

The checklist to hand over before signing

First, pull the incident log for the last twelve months and mark every event with a start time and the time traffic returned to normal. That gives the team its own time-to-mitigation baseline, and it is the number the vendor will be asked to beat. Second, ask each provider what triggers mitigation and how long the trigger takes, in seconds, for an attack under 1 Gbps lasting under ten minutes. A provider that answers in capacity has not answered.

Third, close the protocol exposure that the quarter's vector shift exposes: open DNS resolvers, rate limits on UDP, and any CLDAP rule still sitting in the filter set from the first half of the year. Fourth, keep a capacity clause for the 251 attacks above 1 Tbps and the 49.7-hour Mirai-classified run, because the tail has not disappeared, it has thinned. Fifth, write the short-burst case into the contract as a service level with a measurement method, since neither the report nor the vendor's product page publishes one.

The general lesson comes out of the specific case. The quarter did not make DDoS protection cheaper or easier, it moved the point of failure from the scrubbing centre to the first ten seconds of a small attack, and a renewal negotiated on the old point of failure buys the wrong thing. The buyer who walks into the call with an incident log and one question about the trigger is better armed than the one carrying a capacity slide.