On Saturday 25 July 2026 at 18:02 UTC, a search endpoint flood targeted a crypto exchange customer in North America. The attack peaked at 208.0 million requests per second and lasted 128 minutes. Traffic originated from 1718 autonomous systems in 18 countries, predominantly a headless-browser farm.
| Vector | search endpoint flood |
| Peak | 208.0 million requests per second |
| Duration | 128 min |
| Time to mitigation | 0.236 s |
| Attack traffic reaching origin | 0.064% |
| Legitimate traffic challenged | 0.72% |
Timeline
The attack was preceded by a ransom note demanding payment in Monero. Request rates on the targeted routes exceeded their hourly baseline by a factor of 466 within 40 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
- Keep origin IPs out of public DNS history.
- Lower challenge thresholds on authentication endpoints during high-risk events.
- Enable authenticated origin pulls.
Any plans to support per-tenant limits keyed on a JWT claim?
Great to hear, thanks for sharing your experience.
Clear and practical, thanks.
Machine-readable ranges are at /ips.json and via the API.
We moved from a scrubbing provider to always-on last year; time to mitigation went from minutes to basically nothing.