On Sunday 9 August 2026 at 04:54 UTC, a carpet-bombing UDP flood targeted a B2B SaaS customer in North America. The attack peaked at 310.0 Gbps and lasted 76 minutes. Traffic originated from 2361 autonomous systems in 8 countries, predominantly hijacked home routers.
| Vector | carpet-bombing UDP flood |
| Peak | 310.0 Gbps |
| Duration | 76 min |
| Time to mitigation | 0.755 s |
| Attack traffic reaching origin | 0.074% |
| Legitimate traffic challenged | 0.70% |
Timeline
The attack was preceded by a competitor’s product launch. Edge packet filters identified the flood by source port and payload signature and dropped it at line rate across 37 points of presence.
What the customer saw
A brief increase in p99 latency of 232 ms during the first minute, then normal service.
Recommendations
- Keep origin IPs out of public DNS history.
- Add a dedicated rate limit for the targeted route.
- Review allow-listed partner ranges quarterly.
We had the exact false-positive issue with CGNAT carriers. The weighting change makes sense.
Thanks — sharing this with our on-call team.
Any plans to support per-tenant limits keyed on a JWT claim?
Great write-up. We saw almost the same pattern on our login endpoint last month.
We moved from a scrubbing provider to always-on last year; time to mitigation went from minutes to basically nothing.
Would love a follow-up on how you handle HTTP/3 fingerprinting.
The point about origin IPs leaking through certificate transparency logs is underrated.
The point about origin IPs leaking through certificate transparency logs is underrated.