On Sunday 23 June 2024 at 17:29 UTC, a cache-busting query flood targeted a developer platform customer in Western Europe. The attack peaked at 941.1 million requests per second and lasted 122 minutes. Traffic originated from 2792 autonomous systems in 100 countries, predominantly mobile carrier ranges.
| Vector | cache-busting query flood |
| Peak | 941.1 million requests per second |
| Duration | 122 min |
| Time to mitigation | 0.686 s |
| Attack traffic reaching origin | 0.007% |
| Legitimate traffic challenged | 0.37% |
Timeline
The attack was preceded by a hacktivist channel announcing the target. Request rates on the targeted routes exceeded their hourly baseline by a factor of 251 within 19 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
- Keep origin IPs out of public DNS history.
- Add a dedicated rate limit for the targeted route.
- Enable authenticated origin pulls.
This matches what we see in iGaming around big matches.
Clear and practical, thanks.
Thanks! Yes — the risk score and its components are included in every log record.
Would love a follow-up on how you handle HTTP/3 fingerprinting.
Thanks — sharing this with our on-call team.
Do you publish the edge IP ranges in a machine-readable format?
Machine-readable ranges are at /ips.json and via the API.