On Saturday 4 April 2026 at 03:02 UTC, a cache-busting query flood targeted a video streaming customer in Central Europe. The attack peaked at 339.3 million requests per second and lasted 49 minutes. Traffic originated from 2687 autonomous systems in 49 countries, predominantly residential proxy networks.
| Vector | cache-busting query flood |
| Peak | 339.3 million requests per second |
| Duration | 49 min |
| Time to mitigation | 0.647 s |
| Attack traffic reaching origin | 0.088% |
| Legitimate traffic challenged | 0.04% |
Timeline
The attack was preceded by a breaking political story. Request rates on the targeted routes exceeded their hourly baseline by a factor of 134 within 11 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.
- Enable authenticated origin pulls.
- Review allow-listed partner ranges quarterly.
The point about origin IPs leaking through certificate transparency logs is underrated.
Any plans to support per-tenant limits keyed on a JWT claim?
Thanks — sharing this with our on-call team.
Great write-up. We saw almost the same pattern on our login endpoint last month.
Solid runbook advice. The DNS-at-2am point hit home.
Interesting that most attacks are under ten minutes. Our experience is similar.
We moved from a scrubbing provider to always-on last year; time to mitigation went from minutes to basically nothing.