On Tuesday 5 August 2025 at 01:05 UTC, a HTTP POST flood targeted a news publisher customer in Latin America. The attack peaked at 746.4 million requests per second and lasted 46 minutes. Traffic originated from 463 autonomous systems in 20 countries, predominantly residential proxy networks.
| Vector | HTTP POST flood |
| Peak | 746.4 million requests per second |
| Duration | 46 min |
| Time to mitigation | 0.024 s |
| Attack traffic reaching origin | 0.055% |
| Legitimate traffic challenged | 0.62% |
Timeline
The attack was preceded by a breaking political story. Request rates on the targeted routes exceeded their hourly baseline by a factor of 776 within 37 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
No customer-visible impact. The on-call engineer was notified and acknowledged the incident from the dashboard.
Recommendations
- Review allow-listed partner ranges quarterly.
- Add a dedicated rate limit for the targeted route.
- Enable log streaming to your SIEM for faster correlation.
How do you avoid challenging uptime monitors and partners?
Do you publish the edge IP ranges in a machine-readable format?
Carpet bombing is nasty. Good to see a clear explanation of it.
Could you share the dataset behind the percentages?
The point about origin IPs leaking through certificate transparency logs is underrated.
Thanks! Yes — the risk score and its components are included in every log record.