On Tuesday 3 March 2026 at 22:35 UTC, a search endpoint flood targeted a tax authority portal customer in Western Europe. The attack peaked at 630.0 million requests per second and lasted 144 minutes. Traffic originated from 3117 autonomous systems in 67 countries, predominantly misconfigured open reflectors.
| Vector | search endpoint flood |
| Peak | 630.0 million requests per second |
| Duration | 144 min |
| Time to mitigation | 0.704 s |
| Attack traffic reaching origin | 0.032% |
| Legitimate traffic challenged | 0.75% |
Timeline
The attack was preceded by a competitor’s product launch. Request rates on the targeted routes exceeded their hourly baseline by a factor of 679 within 15 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
The customer’s status page stayed green throughout; they learned about the attack from our notification.
Recommendations
- Enable log streaming to your SIEM for faster correlation.
- Enable authenticated origin pulls.
- Keep origin IPs out of public DNS history.
Could you share the dataset behind the percentages?
How does the proof-of-work challenge behave on older Android devices? Any numbers below Android 10?
Nice to read a vendor blog that admits what went wrong.
Any plans to support per-tenant limits keyed on a JWT claim?
Good question. We will cover that in a follow-up post.
Could you share the dataset behind the percentages?
Verified good bots and allow-listed partners bypass challenges entirely.