On Monday 27 April 2026 at 11:26 UTC, a SYN flood targeted a sports betting customer in Southeast Asia. The attack peaked at 278.7 Gbps and lasted 78 minutes. Traffic originated from 399 autonomous systems in 94 countries, predominantly mobile carrier ranges.
| Vector | SYN flood |
| Peak | 278.7 Gbps |
| Duration | 78 min |
| Time to mitigation | 0.300 s |
| Attack traffic reaching origin | 0.036% |
| Legitimate traffic challenged | 0.61% |
Timeline
The attack was preceded by no stated motive. Edge packet filters identified the flood by source port and payload signature and dropped it at line rate across 26 points of presence.
What the customer saw
The customer’s status page stayed green throughout; they learned about the attack from our notification.
Recommendations
- Review allow-listed partner ranges quarterly.
- Keep origin IPs out of public DNS history.
- Add a dedicated rate limit for the targeted route.
Nice to read a vendor blog that admits what went wrong.
Any plans to support per-tenant limits keyed on a JWT claim?
The billing model is what got our finance team on board, honestly.
Machine-readable ranges are at /ips.json and via the API.
How does the proof-of-work challenge behave on older Android devices? Any numbers below Android 10?
Do you publish the edge IP ranges in a machine-readable format?
Could you share the dataset behind the percentages?
Any plans to support per-tenant limits keyed on a JWT claim?
Verified good bots and allow-listed partners bypass challenges entirely.