June 25, 2022: Cloudflare discloses that it mitigated the largest known HTTP DDoS attack to that date — a barrage peaking above 26 million requests-per-second, launched from a botnet of roughly 5,000 devices against a customer using Cloudflare’s Free plan. Two numbers made the disclosure a milestone. First, the multiplier: 26M rps from ~5,000 bots meant each node contributed over 5,000 requests per second — an order of magnitude beyond the per-node throughput of the era’s classic amplification-driven botnets, achieved through botnets built from virtual machines and hypervisors (the emerging “cloud-based botnet” class) rather than IoT toasters. Second, the source: a potent fraction of the attacking IPs traced to cloud and hosting providers, including Tencent Cloud’s infrastructure being abused via compromised VMs, alongside the usual compromised-server tail. The attack targeted an obscure internet property chosen for its low-defence posture (free-plan customer), hit HTTPS endpoints (encrypted-request flooding — costlier to serve than cleartext), and was absorbed by Cloudflare’s edge without customer-visible outage. The record underscored the 2021–2022 shift in the DDoS landscape — from gigabit-scale volumetric chewing to multi-million-rps application-layer sieges orchestrated with cloud-scale compute — and the corresponding rise of always-on, edge-based scrubbing as table stakes for any internet-exposed property, no matter how small.
In June 2022 (disclosed June 25), Cloudflare reported mitigating the largest-known HTTPS DDoS attack to that point: over 26 million requests-per-second — a record at announcement — aimed at a website on Cloudflare’s Free plan. Attack anatomy: botnet of ~5,000 devices, a large fraction of them cloud-hosted virtual machines/hypervisors (including abuse of Tencent Cloud-hosted infrastructure), yielding per-node throughput above 5,000 rps — versus the hundreds-per-node typical of IoT/Meris-era botnets. The target was chosen for weakness (small, free-plan-hosted internet property — per Cloudflare, an attack-of-opportunity against a low-defence victim) via encrypted HTTPS requests, maximizing per-request server cost; smaller precursor attacks in the preceding weeks ranged from hundreds-of-thousands to tens-of-millions rps as the botnet was tested. Cloudflare’s always-on edge absorbed the traffic with no reported customer outage. Context and cause: the 2021–2022 DDoS era shifted from classic IoT-volumetric chewing to “cloud botnets” — attackers compromising hypervisors/VMs at cloud providers (or renting via stolen cards — less evidence here; major contribution was compromised cloud infra) to generate datacenter-class request rates; mitigations at that scale require anycast-distributed edge scrubbing (no single pipe, no single scrubbing centre), bot/JA3-fingerprint scoring, rate-limiting, and caching-first architectures. 2026 lens: the record-scale arms race continued (records subsequently passed 5Tbps-class volumetric and hundreds-of-millions-rps application markers by 2023–2025), but the June 2022 event’s structural lesson held: cloud-compute-scale botnets collapsed the cost of application-layer DDoS, making hosted-with-CDN/scrubbing the default posture for even hobby-tier internet properties — because the 26M-rps attack proved the floor, not the ceiling, and the victim-selection logic (attack whoever’s cheapest to hurt) hasn’t changed.
What happened
Cloudflare’s June 25, 2022 blog post, “26 million request per second DDoS mitigation,” joined a quarterly series of record announcements — the previous high, 15M rps, had stood from April 2022 (also Cloudflare-mitigated); June’s 26M rps lasted as record-holder until Google’s August 2022 disclosure of a 46M rps mitigation. The attack itself was short (under-a-minute burst class, per Cloudflare’s telemetry) and aimed at a Free-plan website — the tier with baseline protections, selected, evidently, for what it was: low-cost target practice or extortion prep at scale.
The botnet’s unusual potency explained the record. Meris-class botnets of 2021 (built from MikroTik-router compromise) could muster hundreds-of-thousands to millions of rps from tens of thousands of nodes — hundreds of requests per node. The June 2022 botnet achieved more than 5,000 rps per node from only ~5,000 nodes because its muscle was cloud-hosted: virtual machines and hypervisors, compromised or rented, sitting on datacenter uplinks. Cloudflare’s source distribution pointed at a major contribution from Tencent Cloud infrastructure plus the customary compromised-server tail — an awkward disclosure for cloud providers, since the abuse meant their datacenter egress was weaponised against the open internet.
Nothing about the target or technique was exotic — HTTPS GET-flooding against a small site’s encrypted endpoints. The milestone was scale economics: cloud compute gave mid-tier actors datacenter-class request generation, collapsing the marginal cost of application-layer DDoS; the defence that absorbed it (globally distributed anycast edge with always-on mitigation) was already the model, and the event became the canonical argument for it — because the attack arrived at a Free-plan customer, who by definition had chosen to host behind an edge precisely for moments like this.
Anatomy of a cloud-botnet flood
June 2022 record DDoS (26M rps) mechanics:
BOTNET: ~5,000 nodes
composition: cloud VMs/hypervisors
(incl. Tencent Cloud-hosted infra) +
compromised-server tail
per-node: >5,000 rps (datacenter-class
throughput; IoT botnets: ~100s rps)
TRAFFIC: encrypted HTTPS requests
(TLS handshake + application GET)
target cost asymmetry: serving
(decrypt+process) >> sending
TARGET
small Free-plan website
selection logic: cheapest-to-hurt
victim of opportunity
MITIGATION
anycast edge (traffic lands at
nearest PoP, no origin exposure)
bot fingerprinting (JA3/TCP
heuristics) + rate enforcement
absorb: 26M rps peak, no customer
outage reported
ERA CONTEXT (application-layer rps records):
2021-08 Meris network appears
2022-04 15M rps (Cloudflare)
2022-06 26M rps (this event)
2022-08 46M rps (Google/AWS)
2023-25 continued escalation
(volumetric Tbps-class)Impact and numbers
| Metric | Value |
|---|---|
| Announced | June 25, 2022 (Cloudflare blog) |
| Peak rate | >26 million requests/second (record at disclosure) |
| Botnet size | ~5,000 devices |
| Per-node throughput | >5,000 rps (cloud VM/hypervisor class) |
| Botnet composition | Cloud-hosted VMs (major Tencent Cloud contribution) + compromised servers |
| Traffic type | Encrypted HTTPS requests |
| Target | Cloudflare Free-plan website (attack of opportunity) |
| Outcome | Absorbed at edge; no customer outage reported |
| Record succession | 15M rps (Apr 2022) → 26M (Jun 2022) → 46M (Google, Aug 2022) → … |
Timeline
| Date | Event |
|---|---|
| 2021 | Meris botnet (MikroTik-based) ushers in million-rps application-layer era |
| 2022-04 | Cloudflare mitigates previous record 15M rps attack |
| 2022-06 | 26M rps HTTPS flood from ~5,000-node cloud botnet hits Free-plan site; absorbed |
| 2022-06-25 | Cloudflare discloses record mitigation, details cloud-VM botnet anatomy |
| 2022-08 | Google discloses 46M rps mitigation — record falls again inside two months |
| 2023–2025 | Arms race continues: hyper-volumetric Tbps-class attacks, UDP/TCP amplification + cloud-botnet hybrids |
Why it still matters in 2026
Because every trend it flagged finished playing out. Cloud-botnets became the default DDoS engine: by 2023–2025, record disclosures described multi-terabit volumetric behemoths and application-layer floods pushing past hundreds of millions of rps, with compromised cloud workloads and rented GPU/VM fleets as the muscle, and cloud providers spent the era building DDoS-source detection, egress abuse response, and takedown partnerships they’d lacked in 2022 — the Tencent Cloud disclosure being an early, public nudge. The always-on-edge defence model won completely: origin-exposed internet properties joined the endangered-species list, and CDN/DDoS scrubbing became ambient infrastructure, bundled even at hobby tiers, because the June 2022 attack demonstrated the selection logic that punishes exposure — attackers hit whoever is cheapest to hurt, and a Free-plan site absorbing 26M rps without noticing is the entire product pitch. And the HTTPS-flooding cost asymmetry (encrypted request floods tax the defender’s CPU more than the attacker’s) is now a standing argument in every capacity-planning and TLS-termination architecture review: terminate TLS at the edge, cache first, rate-limit per-fingerprint, and never let origin see raw flood traffic. The 26M rps number itself reads quaint from 2026 — but the posture it forced (no origin exposure, ever; mitigation as a property of hosting, not a purchase) is the event’s permanent legacy.
Detection and hardening takeaways
- No origin exposure, full stop. The June 2022 attack validated the model at record scale: anycast-distributed edge with always-on mitigation absorbed 26M rps invisibly. In 2026, allowing direct-to-origin paths (undiscovered subdomains, stale DNS, non-standard ports) is the classic self-own — origin discovery converts a non-event into an outage. Continuous origin-exposure scanning is baseline hygiene.
- Cloud workloads are attacker infrastructure now. The botnet’s muscle was cloud VMs and hypervisors. Organisations running cloud estates should threat-model their own instances as future DDoS nodes: egress monitoring for volumetric anomalies, fast quarantine playbooks for compromised workloads, and credential/SSO hygiene on the management plane (hypervisor compromises were the era’s crown-jewel vector).
- Fingerprint and rate-limit at the edge. Record floods are absorbed by per-client/per-JA3-fingerprint scoring and graduated challenges (JS challenges, CAPTCHAs at suspicion thresholds) rather than IP-list whack-a-mole — the 26M-rps mitigation leaned on distribution plus heuristics, not blocklists; modern edge stacks add behavioural and ML-based bot classification on top.
- Treat TLS as a cost asymmetry to manage. HTTPS floods cost defenders more per request (decrypt + process) than attackers. Terminate TLS at the edge, cache aggressively, push challenge logic pre-origin, and capacity-plan edge termination for flood multiples of normal peak — the attack class specifically punishes origins that do their own crypto under load.
- Watch the record announcements as threat-intel. The 15M → 26M → 46M rps succession inside five months of 2022 told defenders the floor was rising monthly; the 2023–2025 Tbps-class disclosures did the same for volumetric. Capacity plans anchored to last year’s records under-provision; anchor to the trendline, and rehearse flood-response playbooks (challenge escalation, regional shedding, origin lockdown) before the record arrives at your door.
FAQ
How do 5,000 devices produce 26 million requests per second?
Throughput per node, not node count, was the story. Classic IoT botnets muster tens-to-hundreds of rps per device over home uplinks; the June 2022 botnet’s nodes were cloud-hosted virtual machines and compromised servers on datacenter networks, each sustaining 5,000+ rps. Five thousand datacenter nodes × 5,000+ rps = 26M rps — the arithmetic of weaponised cloud compute.
Was this the biggest DDoS ever?
It was the largest HTTPS (application-layer, requests-per-second) attack publicly disclosed at the time. Records are per-metric: the June 2022 event led on rps; volumetric (bits-per-second) records were separate and continued escalate separately — and the rps record itself fell within two months, to Google’s 46M mitigation in August 2022, then kept falling through subsequent years.
Why attack a Free-plan customer?
Victim-selection economics. Attackers of opportunity (testing botnets, extortion prep, grievance) pick targets by cheapness-to-hurt, not by wealth; a small site with baseline defences made convenient target practice. The defensive inversion: hosting behind an always-on edge turned even the Free tier into survivable posture — which is exactly why edge-bundled mitigation became the industry default afterwards.
What could the target have done without Cloudflare?
On their own infrastructure, likely gone dark: absorbing 26M rps of TLS-terminated requests requires datacenter-class anycast distribution that no single-origin deployment can match. The realistic unilateral options are worse — origin IP rotation, ISP upstream filtering, or provider-side scrubbing invoked under duress. That asymmetry (defence requires distribution; distribution requires an edge network) is the structural reason CDN-protection consolidated as the default answer.
