On Tuesday 9 June 2026 at 23:44 UTC, a login endpoint flood targeted a sports betting customer in Central Europe. The attack peaked at 671.5 million requests per second and lasted 26 minutes. Traffic originated from 3011 autonomous systems in 74 countries, predominantly mobile carrier ranges.
| Vector | login endpoint flood |
| Peak | 671.5 million requests per second |
| Duration | 26 min |
| Time to mitigation | 0.423 s |
| Attack traffic reaching origin | 0.071% |
| Legitimate traffic challenged | 0.05% |
Timeline
The attack was preceded by a breaking political story. Request rates on the targeted routes exceeded their hourly baseline by a factor of 425 within 7 seconds. The risk score of participating clients crossed the challenge threshold automatically and proof-of-work difficulty rose with origin load.
What the customer saw
No customer-visible impact. The on-call engineer was notified and acknowledged the incident from the dashboard.
Recommendations
- Add a dedicated rate limit for the targeted route.
- Review allow-listed partner ranges quarterly.
- Enable authenticated origin pulls.
Could you share the dataset behind the percentages?
Do you publish the edge IP ranges in a machine-readable format?
We moved from a scrubbing provider to always-on last year; time to mitigation went from minutes to basically nothing.
The billing model is what got our finance team on board, honestly.
Verified good bots and allow-listed partners bypass challenges entirely.
Solid runbook advice. The DNS-at-2am point hit home.
Do you publish the edge IP ranges in a machine-readable format?
We had the exact false-positive issue with CGNAT carriers. The weighting change makes sense.