On Monday 14 September 2026 at 19:55 UTC, a HTTP/2 rapid reset targeted a electronics retail customer in Southeast Asia. The attack peaked at 580.6 million requests per second and lasted 42 minutes. Traffic originated from 3982 autonomous systems in 114 countries, predominantly a Mirai-derived IoT botnet.
| Vector | HTTP/2 rapid reset |
| Peak | 580.6 million requests per second |
| Duration | 42 min |
| Time to mitigation | 0.757 s |
| Attack traffic reaching origin | 0.047% |
| Legitimate traffic challenged | 0.63% |
Timeline
The attack was preceded by a breaking political story. Request rates on the targeted routes exceeded their hourly baseline by a factor of 535 within 32 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
A brief increase in p99 latency of 133 ms during the first minute, then normal service.
Recommendations
- Enable authenticated origin pulls.
- Review allow-listed partner ranges quarterly.
- Keep origin IPs out of public DNS history.
Great write-up. We saw almost the same pattern on our login endpoint last month.
How do you avoid challenging uptime monitors and partners?
Clear and practical, thanks.
Solid runbook advice. The DNS-at-2am point hit home.
Good question. We will cover that in a follow-up post.
Our auditors asked for exactly this kind of incident evidence under DORA.
We had the exact false-positive issue with CGNAT carriers. The weighting change makes sense.
Could you share the dataset behind the percentages?
Clear and practical, thanks.
How does the proof-of-work challenge behave on older Android devices? Any numbers below Android 10?