On Sunday 13 April 2025 at 01:14 UTC, a HTTP/2 rapid reset targeted a ticketing customer in Western Europe. The attack peaked at 265.3 million requests per second and lasted 104 minutes. Traffic originated from 4189 autonomous systems in 47 countries, predominantly misconfigured open reflectors.
| Vector | HTTP/2 rapid reset |
| Peak | 265.3 million requests per second |
| Duration | 104 min |
| Time to mitigation | 0.923 s |
| Attack traffic reaching origin | 0.053% |
| Legitimate traffic challenged | 0.59% |
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 788 within 24 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
Checkout conversion was unchanged compared with the same hour of the previous week.
Recommendations
- Add a dedicated rate limit for the targeted route.
- Enable log streaming to your SIEM for faster correlation.
- Lower challenge thresholds on authentication endpoints during high-risk events.
Could you share the dataset behind the percentages?
Could you share the dataset behind the percentages?
Is the risk score exposed in the logs so we can build our own dashboards on it?
Machine-readable ranges are at /ips.json and via the API.
Would love a follow-up on how you handle HTTP/3 fingerprinting.