HTTP/3 in Burp Suite

Published: Wednesday, 23 September 2026 at 14:00 UTC Updated: Wednesday, 23 September 2026 at 15:27 UTC How many bugs have you missed because you didn’t send quite enough HTTP requests? Turbo Intruder now supports HTTP/3, can comfortably exceed 100,000 requests per second over Wi-Fi, and auto-tunes for maximum performance. With our new HTTP/3 Adapter plugin, Burp Suite now supports HTTP/3 too. Read on to learn how to use this new toolkit to: In Embracing the Billion Request Attack we were able to hit 30,000 requests per second (RPS) over HTTP/1.1. From my laptop while using the HTTP3 engine, I was able to hit 100,000 RPS to a remote host over Wi-Fi. When fuzzing over any protocol, you’ll first want to minimise the size of your request and response (using the HEAD method, or Range header). GET / HTTP/1.1 Range: bytes=-1 //Only return the last byte HTTP/1.1 206 Partial Content Content-Range: bytes 9999-9999/10000 Content-Length: 1 > The Host header can be skipped when using theHTTP3 engine because the:authority pseudo header is implied by the target. Next, you’ll want to adjust the engine’s configuration. If you’re using Burp Suite Professional, you can simply swap to the AUTO engine, which will automatically select the highest HTTP version available and then dynamically tune the required settings as your attack runs. This is particularly powerful for long-running attacks, where the network state may degrade or improve over time. HTTP/1.1's pipelining feature is not supported in the AUTO engine. You may be able to achieve higher RPS over HTTP/1.1 when using theTHREADED engine if you enable pipelining manually. If you’re attempting a desync attack, AUTO is not recommended. Instead use theBURP engine which uses HTTP/1.1 with connection reuse disabled. If you’re using the Community Edition, you’ll need to configure each setting manually depending on the engine. For each setting you want to increase its value until the RPS counter plateaus, or you start seeing failures. The only exception to this, is when using the THREADED engine’s pipeline option, which should be set to True if the server supports it. Available tuning options: | Engine | Tuning Options | |---|---| | THREADED | concurrentConnections requestsPerConnection pipeline=True | | BURP2 | concurrentConnections | | HTTP3 | concurrentConnections | If you require more speed, run the attack from a box in the cloud that’s hosted in the same region as your target to push the RPS even higher. My best result so far was ~180,000 RPS. To complement the HTTP3 engine, you can now try out two new race condition techniques. The Single Datagram Attack from QUIC-er Races: HTTP/3 won’t save you from TOCTOU vulnerabilities and Server-Side Race Orchestration via the QPACK Blocked Streams technique from Chaos by Design: The Death of Stochastic Race Conditions in HTTP/3. These techniques will give you better groupings than the already blazingly fast Single-Packet attack if the target supports HTTP/3 so you can hit smaller race windows. Both are only accessible when using the HTTP3 engine and are built into the existing gate system. Turbo Intruder will select the race technique automatically and it only uses the QPACK method if the server supports it. Set gateMode to force one of the options. You can use the race-http3.py example script to get started. def queueRequests(target, wordlists): engine = RequestEngine(endpoint=target.endpoint, concurrentConnections=1, engine=Engine.HTTP3, gateMode='auto' #Select the correct technique for me ) for i in xrange(20): engine.queue(target.req, gate='race1') engine.openGate('race1') def handleResponse(req, interesting): table.add(req) Turbo Intruder also supports kettled request syntax in the HTTP3 engine in exactly the same way as the BURP2 engine. This is achieved via a set of special character escapes. For a request to be kettled, you must now specify engine.queue(target.req, kettled=True) . It’s worth noting that kettled requests undergo some implicit transformations. :path and :method pseudo headers are implied by the HTTP/1 style request line:authority and :scheme pseudo headers are implied by the request targetTo override pseudo headers yourself: GET / HTTP/1.1 :scheme: httpx :authority: intranet.example.com Additionally, you can add the binary representations of special characters using the following escapes: | Character | Escape | |---|---| | CRLF | ^~ | | space | ^s | | null | ^0 | | CR | ^r | | LF | ^n | | Any hex code e.g. 0x02 | ^x02 | | Literal ^ character | ^^ | For example, if you wanted to attempt a HTTP/3 downgrade header injection you could try: GET / HTTP/1.1 foo: bar^~Transfer-Encoding:^schunked engine.queue(target.req, kettled=True) This would attempt to inject the Transfer-Encoding: chunked header once the target downgrades the request from HTTP/3 to HTTP/1. GET / HTTP/1.1 Host: example.com Foo: bar Transfer-Encoding: chunked I’m also introducing support for HTTP/3 traffic across all of Burp Suite’s tooling in another extension, the HTTP/3 Adapter. The extension will convert all traffic from HTTP/1.1 or HTTP/2 to HTTP/3 and reverse the operation for responses. This means that you can now test sites that only support HTTP/3 and reach a new attack surface that was previously hidden. Load the extension and pick a mode. | Mode | Explanation | |---|---| | Explicit HTTP/3 only | Only requests carrying the X-Http3: 1 header are sent over HTTP/3 | | Always HTTP/3 where possible | Every request tries HTTP/3 first and falls back to its original protocol | In Explicit HTTP/3 only mode, the following will force the request over HTTP/3. GET / HTTP/1.1 Host: example.com X-Http3: 1 HTTP/1.1 200 OK X-Http3: 1 In Always HTTP/3 where possible the X-Http3: 1 header is not required. If the host supports HTTP/3, the request will be sent over HTTP/3. GET / HTTP/1.1 Host: example.com HTTP/1.1 200 OK X-Http3: 1 The adapter’s settings can be found under a settings panel named HTTP/3 Adapter. If a request is misbehaving, turn on the Log exchange to output option to log both the original and converted request to the extension output pane. You can also enable a new Burp Suite tab called Show unsupported origins tab , which is useful when testing multiple different domains using the Always HTTP/3 where possible mode. This view will tell you which domains are failing their HTTP/3 handshake. I’ve introduced HTTP/3 support in Turbo Intruder and Burp Suite as well as the all new AUTO engine, allowing you to fuzz targets at insane speeds, exploit HTTP/3 exclusive race conditions and target previously hidden attack surfaces. You can get your hands on both extensions at the links below and in the BAPP store.