Cloudflare warns of a 519% surge in massive DDoS attacks

Cloudflare says it blocked 23.2 million network-layer DDoS attacks during the first six months of 2026, approximately 5,343 attacks every hour. Its new report particularly highlights growth in hyper-volumetric events: 935 attacks exceeded one terabit per second, with a 519% increase between the first and second quarters.

These measurements do not describe every attack on the Internet. They come from Cloudflare's network and customers, creating an enormous but necessarily partial observation point. They nevertheless reveal a useful shift for infrastructure teams: extreme events are multiplying, while DNS and CLDAP have regained a central role in reflection and amplification.

The short answer

Attacks above 1 Tbps are changing scale

Cloudflare defines a hyper-volumetric attack as one exceeding 1 Tbps, one billion packets per second or one million requests per second. In Q2, it mitigated 805 network attacks crossing the terabit threshold alone, more than six times the previous quarter's volume.

Such traffic greatly exceeds most enterprise links and can saturate an unprotected data center before application servers process a single request. The answer is not to purchase a network interface matching the peak. Defense must distribute and filter traffic upstream through infrastructure with sufficient capacity and geographic reach.

The headline figure should not obscure the ordinary attack profile. Cloudflare reports that 96.62% of network attacks remained below 500 Mbps. That may be small for a global carrier, but 100 Mbps can still overwhelm a modest server or constrained connection. An attack does not need to set a record to succeed.

Short, automated and too fast for a manual response

More than nine in ten attacks observed by Cloudflare ended within ten minutes. That short duration weakens a response based on opening a ticket, holding a meeting and writing a rule manually. By the time a team identifies the vector, the burst may be over, despite having caused downtime and being ready to return in another form.

Protection must automatically identify an anomaly, generate a targeted signature and distribute it to the right entry point. Cloudflare says its systems analyze packet fields, HTTP request characteristics, origin errors and traffic rates. Temporary mitigation rules expire when the attack pattern disappears.

Automation still needs oversight. Excessive sensitivity can block a product launch or legitimate surge, while weak sensitivity lets a slow attack through. Teams need a baseline, usable logs and a procedure for tuning rules without disabling all protection under pressure.

DNS becomes the primary network battleground

DNS-based attacks represented 34.3% of network DDoS activity in the half-year, according to Cloudflare. DNS floods alone rose from 25.7% to 40% of attacks between the two quarters. A flood sends a huge number of queries directly to authoritative DNS servers to exhaust their capacity. When those servers stop responding, the service becomes difficult to reach even if the application is still running.

DNS amplification uses a different method. An attacker queries accessible resolvers while spoofing the victim's IP address. A small request triggers a larger response directed at the victim. The ratio between traffic sent and received makes this technique economically attractive.

DNS resilience should therefore be treated as a production dependency. It requires multiple servers, distributed deployment, sufficient absorption capacity, appropriate limits and monitoring separate from the website. A green HTTP dashboard does not prove that the domain can still be resolved.

CLDAP grows by 580%

Cloudflare measured a 580% quarterly increase in CLDAP floods, which became the third-largest vector in Q2. CLDAP is a connectionless form of LDAP using UDP. The lack of a session handshake makes source-address spoofing easier, allowing a response to be reflected toward a victim.

Internet-exposed CLDAP services, often associated with poorly filtered directory environments, can become involuntary amplifiers. The operator is not necessarily the target; its infrastructure participates in an attack against someone else. Organizations should inventory exposed UDP services, remove public access where it is unnecessary and filter flows at both firewall and provider levels.

Address-spoofing prevention is a collective responsibility as well. Egress filtering by access networks reduces an attacker's ability to impersonate a victim. One organization cannot repair the whole Internet, but it can ensure its own systems and addresses do not contribute to the problem.

Media is the most targeted sector

Media, production and publishing accounted for 14.2% of HTTP DDoS requests mitigated by Cloudflare and ranked first in both quarters. The company connects that pressure with coverage of conflicts and major international events. The figures cannot attribute every attack to a state or named group, but they show how current events can quickly change a site's risk.

A newsroom, video platform or local publisher should include sensitive dates in capacity planning. Publishing an investigation, an election, a conflict or a sporting event can combine exceptional legitimate demand with an attack. Separating the two requires rules informed by paths, HTTP methods, sessions and behavior rather than one global request threshold.

Attacks may also target an API, distribution server, VPN or DNS instead of the homepage. Continuity planning must map every public entry point and critical provider.

Five controls to check now

The first control is to prevent direct exposure of the origin address. If an attacker can bypass the CDN or proxy and reach the server, it can saturate the link or resources without meeting edge protections. The origin should accept traffic only from authorized front-end ranges and authenticated mechanisms.

Next, review managed DDoS rules, the WAF and rate limiting. Cloudflare recommends keeping managed rules at their default sensitivity and action, then adding controls based on known application use. Cache should absorb as much content as possible, and unnecessary query parameters in cache keys should be reviewed so randomized values do not always force a trip to origin.

Third, monitor the website, DNS, API, network and administration services separately. Fourth, prepare provider, hosting and registrar contacts together with emergency accounts protected by MFA. Finally, run an exercise simulating loss of the primary edge and test the status page, communications and configuration restoration.

Cloudflare's report does not mean every website will face a terabit attack tomorrow. It shows that manual defense and server capacity alone are no longer credible strategies. The right objective is to filter extreme volume automatically while preserving enough visibility to detect the smaller events that can still stop modest infrastructure.