Turbo Intruder hits 100,000 requests a second from a laptop over HTTP/3

PortSwigger reports 100,000 requests per second to a remote host, sent from a laptop over Wi-Fi using the new HTTP/3 engine ^[2]. The same team's earlier "Billion Request Attack" work topped out at 30,000 RPS over HTTP/1.1 ^[3]. That is a 3.3x jump on the same kind of hardware ^[9], and moving the attack box into the cloud in the target's region took the author's best result to about 180,000 RPS ^[8].

Speed changes what a wordlist costs to run. A fuzzing pass that took an hour over HTTP/1.1 finishes in under twenty minutes at the new rate, so lists that were too large to be worth trying become practical ^[9]. The tooling reduces the per-request cost further: it recommends the HEAD method or a Range header to shrink request and response bodies, and the HTTP/3 engine lets you drop the Host header because the :authority pseudo-header is implied by the target ^[4][5].

For anyone running Burp Suite Professional, the engine change is a menu setting. The AUTO engine picks the highest available HTTP version and tunes its settings while the attack runs, which the write-up says matters most for long-running attacks "where the network state may degrade or improve over time" ^[6]. Community Edition users tune each option by hand, raising values until the RPS counter plateaus or failures appear ^[7].

The release also adds two race-condition techniques that only work over HTTP/3: the Single Datagram Attack and Server-Side Race Orchestration using QPACK blocked streams ^[10]. PortSwigger says these give tighter groupings than its existing Single-Packet attack when the target supports HTTP/3, letting an attacker hit smaller race windows ^[11]. Turbo Intruder selects the technique automatically and only uses the QPACK method if the server supports it ^[12].

Rate limiting, WAF inspection, and request logging were built and tuned against HTTP/1.1 and HTTP/2 traffic. A middlebox that does not parse QUIC sees encrypted UDP and passes it through, and a rate limiter that counts connections undercounts by whatever the engine multiplexes onto one connection. The example race script opens a single connection and queues twenty requests through it ^[13]. PortSwigger did not test defensive gear in this write-up, so the failure mode is inference from how the transport works, not a measured result. The engine also carries the older kettled-request syntax into HTTP/3, including a header-injection example that tries to smuggle a Transfer-Encoding: chunked header through an HTTP/3 to HTTP/1 downgrade ^[14].