QUIC Broadcast Flaw: How a Single Initial Packet Amplified into a Flood
Cloudflare has patched a broadcast address amplification vulnerability in its QUIC infrastructure after anonymous security researchers reported it through the company's Public Bug Bounty program. The flaw allowed a single client QUIC Initial packet sent to a broadcast IP destination to trigger a large response of Initial packets, creating both a server CPU amplification attack and a reflection amplification attack.
Why QUIC's Handshake Leaves a Gap
Unlike TCP and TLS, which use separate handshakes that validate the client IP address before any cryptographic work begins, QUIC combines transport and security handshakes into a single sequence. A client sends an Initial packet containing a ClientHello, and the server responds with its own Initial packet containing a ServerHello and certificate—without first verifying the client's IP address.
RFC 9000 acknowledges this risk and provides guardrails. Servers enforce an anti-amplification limit, sending no more than 3x the bytes they receive until the client address is verified. They can also initiate address validation early by responding with a Retry packet, though this adds a round-trip to the handshake, eroding QUIC's performance advantage. In practice, deployments use heuristics to balance these mitigations against latency.
The Broadcast Address Problem
The vulnerability stems from how IPv4 broadcast addresses behave, both within a subnet and across the wider Internet. The final address in any IPv4 subnet is designated as a broadcast address, delivering packets to every node in that range. This behavior, enabled by default on most networked systems, is essential for local device discovery.
Routers typically block broadcast packets originating from outside their own subnet to prevent remote DDoS amplification. However, that protection only applies when a router is directly connected to the target subnet. For subnets that are routed remotely, the "broadcast" address is treated like any other IP address—BGP and other routing protocols forward traffic toward it normally. The address only functions as a broadcast within the local scope of routers and hosts connected via Ethernet.
Cloudflare uses Anycast routing, so each server must listen on every Anycast IP address in the network. This is achieved by binding IP ranges to the loopback interface, which makes all addresses in a range available to the kernel. When a range is bound this way, Linux's routing infrastructure adds both local and broadcast routes automatically. The local route ensures all addresses are processed locally; the broadcast route causes packets sent to the final address to be replicated to every address in the range.
How the Amplification Worked
Cloudflare's frontend runs multiple worker processes, each binding independently to the full anycast range on UDP port 443 using the SO_REUSEPORT socket option. While this enables multiple processes to share the same port, it also means traffic sent to the broadcast address is copied to every listener.
The researchers found that sending a QUIC Initial packet to one of Cloudflare's broadcast addresses—in the example system, the final address in the 203.0.113.0/24 prefix bound to the loopback interface—triggered every QUIC server worker to respond independently. Each worker reacted to the same Initial packet, duplicating the server-side work and generating response traffic to the client's IP address. On a 128-core system with one listener per core, a single packet could produce up to 384 replies, far exceeding the RFC's 3x amplification limit.
The issue isn't limited to QUIC. Any UDP request/response protocol using multiple listening sockets in this manner could exhibit the same amplification behavior.
The Fix: Removing Broadcast Routes
Broadcast delivery is not desirable for anycast prefixes, so Cloudflare's mitigation focused on disabling broadcast functionality for the final address in each range. The ideal approach—modifying their internal tooling to add only local routes and skip broadcast routes—would have required maintaining a fork of the iproute2 suite, an impractical overhead.
Instead, Cloudflare removed the broadcast routes directly using standard tooling and made a small change to its deployment system to strip these routes from the loopback interface at scale. With the broadcast routes gone, the specification-defined broadcast address is treated no differently than any other address in the range, eliminating the amplification vector. According to Cloudflare's analysis, the vulnerability is fully patched and the amplification vector no longer exists.
Other organizations with similar infrastructure—multi-worker, multi-listener UDP services bound to all IP addresses on a machine with routable IP prefixes exposing broadcast addresses—should assess whether they need comparable mitigations.
