DDoS Attacks in 2026: What Changed and How to Protect Your Company

If your defence against a denial-of-service attack is a person noticing and calling somebody, you do not have a defence. Cloudflare mitigated 23.2 million network-layer DDoS attacks in the first half of 2026, and 90.60% of them ended in under ten minutes. The attack is over before a human finishes reading the alert. The answer is always-on automated mitigation in front of your public endpoints, an anycast network that absorbs volume, and hardened DNS. Everything else is secondary.

This guide covers what a DDoS attack is, what the 2025 and 2026 telemetry from network operators actually shows, the attack vectors that changed, and the seven controls that matter in order of how much protection they buy.

What a DDoS Attack Is

A distributed denial-of-service attack disrupts a server, service or network by flooding it with traffic from many sources at once. The traffic is not trying to steal anything. It is trying to consume a finite resource: bandwidth, connection table entries, CPU cycles, database connections. When that resource runs out, legitimate requests fail.

The traffic usually comes from a botnet, a network of compromised devices under one operator's control. Home routers, IP cameras and other internet-connected hardware make up most of it, because they ship with weak defaults, rarely get patched, and sit on residential connections that are hard to block wholesale. Compromised cloud instances add high-bandwidth nodes to the same pool.

Two things follow from that. Blocking source addresses does not work at scale, because there are millions of them on networks you cannot afford to block. And attack capacity keeps growing without the attacker spending more money, because the supply of poorly secured devices keeps growing.

The Three Types of DDoS Attack

CISA, the FBI and MS-ISAC use the same three-way split in their joint DDoS guidance, and it is still the most useful way to think about defence, because each type is stopped in a different place.

1. Volumetric attacks

Raw bandwidth exhaustion. UDP floods and reflection or amplification attacks that bounce small requests off open servers to produce large responses aimed at you. These are stopped upstream, by a provider with more capacity than the attacker. Nothing you run inside your own network helps once the pipe is full.

2. Protocol attacks

Exhaustion of connection state rather than bandwidth. SYN floods and similar techniques fill the tables in firewalls, load balancers and servers so no new connection can be established. These are stopped by scrubbing infrastructure and by stateless filtering at the edge.

3. Application-layer attacks

Requests that look legitimate but are expensive to serve: search queries, login attempts, anything that hits a database. Volume can be modest and still take a site down. These require request-level inspection, rate limiting and bot management, which means they are stopped by whatever sits closest to your application.

What the 2025 and 2026 Data Actually Shows

The headline numbers and the typical attack have pulled apart, and most coverage misses it. Both trends are in the same reports.

The ceiling is rising fast. Cloudflare blocked a 7.3 Tbps attack in June 2025, then 29.7 Tbps in the third quarter, then 31.4 Tbps in the fourth, that last one lasting 35 seconds. Microsoft separately reported neutralising a cloud attack of more than 15 Tbps against a single endpoint in October 2025. In the first half of 2026, Cloudflare mitigated 935 attacks above 1 Tbps, 805 of them in the second quarter alone, a 519% increase quarter over quarter.

The median attack is small and brief. In the same six months, 96.62% of network-layer attacks stayed under 500 Mbps and 90.60% finished in under ten minutes. NETSCOUT's telemetry for the second half of 2025 is consistent: about half of attacks lasted five to fifteen minutes, and only 0.19% exceeded 100 Gbps.

Measure	Figure	Period
Network-layer attacks mitigated (Cloudflare)	23.2 million	H1 2026
HTTP DDoS requests mitigated	29.64 trillion	H1 2026
Attacks above 1 Tbps	935 (+519% QoQ in Q2)	H1 2026
Attacks ending in under 10 minutes	90.60%	H1 2026
Attacks under 500 Mbps	96.62%	H1 2026
Largest single attack on record	31.4 Tbps, 35 seconds	Q4 2025

Read together, those two facts set the requirement. Defence has to be automatic, because there is no time for a human decision. And it has to have headroom you will almost never use, because the tail of the distribution is where the business-ending attack lives.

One caveat on industry rankings. Cloudflare's most-attacked industry in the first half of 2026 was media, production and publishing, at 14.2% of mitigated HTTP requests. Akamai's 2026 State of the Internet report puts commerce at the top of its own data, and NETSCOUT emphasises government, finance and telecom. Those lists reflect each provider's customer mix as much as the threat, so treat them as directional.

The Vectors That Changed

DNS is now the main event. DNS-based attacks made up 34.3% of network-layer activity in the first half of 2026, and DNS floods alone rose from 25.7% of attacks in the first quarter to 40.0% in the second. CLDAP amplification grew 580% quarter over quarter to become the third most common vector. If your authoritative DNS is self-hosted on two servers in one region, that is the weakest link in your availability story.

Carpet-bombing spreads the load. Instead of one target address, the attack is split across an entire address range, averaging around 15,000 destination ports per second in the 29.7 Tbps case. Per-host thresholds never trigger, so detection tuned to a single victim IP misses it entirely.

HTTP/2 abuse did not end with Rapid Reset. The 2023 Rapid Reset technique (CVE-2023-44487) produced the largest layer-7 attack on record at 398 million requests per second and was widely patched. In August 2025 researchers disclosed a follow-on technique, MadeYouReset, tracked as CVE-2025-8671 and documented in CERT/CC VU#767506. Where Rapid Reset relied on the client cancelling streams, MadeYouReset provokes the server into sending the reset, which sidesteps the mitigations added after 2023. Confirmed affected implementations include Apache Tomcat, Varnish, Netty and F5 BIG-IP; Go, HAProxy, Node.js and Envoy were confirmed not affected. There is no confirmed in-the-wild exploitation, so this is a patching item rather than an emergency.

The botnets got larger. The record attacks of late 2025 came from the Aisuru family, a Turbo Mirai-class botnet built from compromised consumer devices with an estimated one to four million infected hosts. Cloudflare mitigated 1,304 hyper-volumetric attacks in the third quarter of 2025 alone, around fourteen a day.

Ransom DDoS still exists but is not the main risk. Cloudflare recorded a 68% quarter-over-quarter rise in ransom DDoS reports in the second quarter of 2025. That metric was not carried into the 2026 half-year report, so treat it as a 2025 data point rather than a current trend. Paying does not buy anything durable, and the FBI's standing advice against paying extortion applies.

What an Attack Actually Costs

Precise per-hour downtime figures deserve scepticism, because they are almost always survey estimates rather than audited losses. A more defensible framing comes from the Uptime Institute's 2026 outage analysis. There, 57% of respondents said their most recent significant outage cost more than $100,000. One in five said their most recent impactful outage cost more than $1 million, the second consecutive year at that level. Those numbers cover outages of all causes, not DDoS specifically.

For most companies the real cost is not the lost hour of revenue. It is the contractual availability commitment you just missed, the enterprise customer who now wants to discuss your resilience, and the engineering weeks spent on an unplanned migration to a provider you should have been using already.

Seven Controls That Actually Help

In rough order of protection bought per unit of effort.

1. Put always-on automated mitigation in front of everything public

This is the whole game. Given that nine in ten attacks are over inside ten minutes, any scheme that requires someone to notice, decide and reroute traffic has already failed. On-demand mitigation that you switch on during an attack is materially weaker than always-on. Confirm with your provider that mitigation is automatic, that it covers layers 3, 4 and 7, and what the documented time to mitigate is.

2. Use anycast and a CDN so volume has somewhere to go

A content delivery network distributes traffic across many points of presence near users. An attack aimed at one origin gets spread across a network with far more aggregate capacity than the attacker, and cached content keeps being served while the origin is under pressure. This is also the only realistic defence against a volumetric attack: you cannot buy 30 Tbps of transit, and your provider already has it.

3. Hide and harden the origin

All of the above is worthless if the attacker can reach your origin servers directly. Restrict origin firewall rules to your provider's published address ranges, rotate origin addresses after any exposure, and check that historical DNS records, mail servers, staging hosts and TLS certificate transparency logs are not advertising the real address.

4. Treat DNS as production infrastructure

DNS is the leading attack vector now and it is a single point of failure for everything you run. Use an anycast authoritative DNS provider with its own DDoS protection, keep records at more than one provider if availability is contractual, and set TTLs low enough that you can actually reroute during an incident.

5. Rate-limit and manage bots at the application layer

Application-layer attacks do not need volume, so they need different controls: per-client rate limits on expensive endpoints, caching in front of anything that can be cached, and bot management on login, search and checkout paths. Query and index tuning belongs here too, because a slow endpoint is a cheaper target than a fast one.

6. Audit and exercise, rather than assume

Regular review of your own posture is still the starting point. What is exposed to the internet? Which addresses bypass the CDN? Does the mitigation configuration match what you think you bought? Do the availability terms in your provider contract match the ones in your customer contracts? Then exercise the response. A plan nobody has rehearsed is a document.

7. Have a response plan people have actually read

The plan should be short and specific: who declares an incident, who talks to the upstream provider and on which phone number, which dashboards confirm it is an attack rather than a bad deploy, what the status-page message says, and who tells customers. Not every attack is obvious. Low-volume attacks are sometimes used as a distraction or a probe, so treat unexplained slowness as a possible signal rather than an anomaly to ignore.

Two upstream practices are worth asking your network provider about, both long-standing internet hygiene rather than products you buy: ingress filtering to reject spoofed source addresses, described in BCP 38 (RFC 2827), and routing security measures such as RPKI origin validation, covered in NIST SP 800-189.

The First Ten Minutes

1. Confirm it is an attack, not a deploy, a dependency outage or a viral traffic spike. Check request volume, error rates and origin health together.
2. Verify automated mitigation engaged, and check whether traffic is reaching the origin directly.
3. Open the ticket with your mitigation provider immediately, even if you think it is handled. Their telemetry is better than yours.
4. Post a status update before customers ask. Availability incidents damage trust through silence more than through downtime.
5. Do not change DNS or reroute traffic under pressure unless the plan already said to. Most self-inflicted extensions of an outage happen here.
6. Preserve logs and mitigation reports for the post-incident review and for any contractual obligation.

Availability is one part of a wider posture. The controls that reduce the rest of the risk, from phishing-resistant authentication to patching what is actually being exploited, are covered in the guide to data security practices that hold up.

How This Guide Was Put Together

The figures here come from network operators publishing their own mitigation telemetry, not from surveys or secondary coverage: Cloudflare's DDoS threat reports for the third and fourth quarters of 2025 and the first half of 2026, Microsoft's Azure infrastructure blog, Google Cloud's published analysis of the 2023 Rapid Reset attack, NETSCOUT's threat intelligence highlights, and Akamai's 2026 State of the Internet report. Vulnerability details were checked against the CERT Coordination Center advisory. Guidance references are to CISA and NIST publications. This is an analysis of published operator data; it makes no claim of hands-on product testing.

Two deliberate omissions. A widely repeated requests-per-second figure attached to the 31.4 Tbps attack appears only in secondary coverage and is not in Cloudflare's own report, so it is not used here. And no primary source has published third-quarter 2026 telemetry yet, so the most recent verified data covers January through June 2026.

Last verified: September 2026. Checked: Cloudflare H1 2026 report figures, record attack sizes and dates, DNS and CLDAP vector shares, CVE-2025-8671 advisory status and affected implementations, Uptime Institute 2026 outage costs, CISA and NIST guidance URLs.

Frequently Asked Questions

Can a small company be hit by a DDoS attack?

Yes, and it is more likely than the headline numbers suggest. Attack services are cheap, and the overwhelming majority of attacks are under 500 Mbps, which is enough to take down a single unprotected server. Small targets are hit opportunistically, as collateral on shared hosting, or by someone with a grudge.

How do I tell a DDoS attack from a traffic spike?

Look at the shape rather than the size. Attack traffic usually shows an abrupt onset, a narrow distribution of request paths or packet types, source geography that does not match your customers, and error rates rising faster than throughput. Genuine spikes usually have a cause you can find in a referrer, a campaign or a news event.

Is a firewall enough?

No. A firewall sits inside the bottleneck for a volumetric attack, so it fails at the same moment your link saturates, and its state table is itself a target for protocol attacks. Firewalls remain necessary for other reasons and are not a DDoS control.

Does moving to the cloud protect me?

Partly. Major cloud providers absorb network-layer attacks against their own infrastructure and offer dedicated protection tiers, but application-layer attacks still reach your application and still cost you money. Autoscaling without rate limits converts a denial-of-service attack into a denial-of-wallet attack.

Should we pay a ransom DDoS demand?

No. Payment marks you as a target that pays, funds the next attack, and buys no enforceable commitment. Report it to law enforcement and route the traffic to your mitigation provider.

Can I test my own defences?

Yes, with written authorisation from every provider in the path, because unauthorised load testing against shared infrastructure breaches most acceptable use policies and several laws. Most mitigation vendors will run a controlled exercise with you, which is the safe way to find out whether your configuration does what you think.