Turbo Intruder: a Burp extension built to outpace Burp Intruder

What it is for, and what it is not for

Turbo Intruder is a Burp Suite extension for sending large numbers of HTTP requests and analyzing the results. The README is explicit about the scope: it is intended to complement Burp Intruder by handling tasks that require exceptional speed, duration, or complexity.

That framing matters, because it defines what you should not use it for. If you are fuzzing a parameter with a few hundred payloads, core Burp Intruder is the tool, and Turbo Intruder would be adding friction for nothing.

The four claims that set it apart are stated as a list. It is fast, because it uses an HTTP stack hand-coded from scratch with speed in mind, and as a result on many targets it can seriously outpace even fashionable asynchronous Go scripts. It is scalable, achieving flat memory usage, which enables reliable multi-day runs, and it can be run in headless environments via the command line. It is flexible, because runs are configured using Python, which enables handling complex requirements such as signed requests and multi-step sequences, and because the custom HTTP stack means it can handle malformed requests that break other libraries. And it is convenient, because boring results can be automatically filtered out by an advanced diffing algorithm adapted from Backslash Powered Scanner, which means you can launch a run and obtain useful results in two clicks.

The author is also candid about the downside: it is undeniably harder to use, and the network stack is not as reliable and battle-tested as core Burp's. Since this is a tool for advanced users only, no personal support is offered to anyone having trouble using it.

One scope limit is worth repeating because it is easy to get wrong. It is designed for sending lots of requests to a single host. If you want to send a single request to many hosts, the recommendation is ZGrab.

The engines, and the trade each one makes

The documentation index names the engine types as THREADED versus BURP versus BURP2 versus HTTP3, and the existence of four engines tells you the important design decision: the speed comes from choosing what to give up.

A hand-written stack can be much faster because it does only what the task needs, but it is the part that is not battle-tested, and the author says so directly. The engines that route through Burp's own stack trade throughput for the reliability of a stack that has been hardened by years of use.

The race conditions page is the one that explains why the extension exists at all. It covers gated requests and timing tests, which are the class of problem where the ordering and timing of a request matters rather than the content. If you are testing a state machine and you need many requests in flight simultaneously, a sequential client cannot express the question, and a tool that is fast enough and flat enough in memory lets you ask it over days rather than minutes.

The single-packet attack reference implementation is a related piece. If you are interested in creating your own implementation of the single-packet attack, the reference implementation is in the SpikeEngine and SpikeConnection source files, and it was built on Burp Suite's native HTTP/2 stack. The claim is that it should be possible to make a similar implementation using any HTTP/2 library that provides a frame-level interface, and the author notes having seen Go's HTTP/2 stack used for some frame-level attacks, which might be a good choice.

That is a genuinely useful piece of engineering documentation. A frame-level HTTP/2 interface is what makes the attack expressible, and the reference implementation shows what it takes.

Response processing, and the diffing that makes results usable

Sending a million requests is only half the problem, and the extension has a substantial answer for the other half.

The response processing page covers callbacks and filtering, and the decorators page covers response filtering decorators as a separate concept, which is a good sign of structure. A decorator is a wrapper that transforms or inspects a response before it reaches your display, so a common filter can be applied across many runs without being rewritten each time.

The filtering that gets the most attention is the diffing algorithm adapted from Backslash Powered Scanner. The claim is that boring results can be filtered out automatically, so you can launch a run and obtain useful results in two clicks. The reasoning is sound for this kind of work. When you send a million requests and get a million responses, almost all of them differ only in a request identifier or a timestamp, and reading them one by one is not a plan. Diffing collapses the set to the responses that are actually different, which is usually a handful.

The wordlist and misc page covers the utilities, and the settings page is a full parameter reference rather than a summary, which is what you would expect from a tool where the parameters are the tuning surface.

The performance tuning page exists for the same reason. Maximising requests per second is a measurement problem, and a tool that exposes its own parameters without explaining them would leave you guessing.

Building it, and the packaging

The build is a Gradle build producing a fat jar, and the commands are given per platform:

Linux: `./gradlew build fatjar`

Windows: `gradlew.bat build fatjar`

The output lands in build/libs/turbo-intruder-all.jar, which is the file Burp loads as an extension.

The repository layout shows what a Burp extension project involves beyond the Kotlin sources. There is BappDescription.html and BappManifest.bmf, which are the Burp Extension Store metadata, and resources/ for the extension's own assets. There are two vendored jars at the top level, albinowaxUtils-all.jar and hpack-1.0.2.jar, the latter being the HPACK header compression implementation that HTTP/2 requires, which is a strong hint about the HTTP/2 story.

The src/ directory holds the Kotlin implementation, and the test/ directory the tests. There is also a plan document, PLAN-ttfb-ttlb.md, and an analysis document, ANALYSIS-vrt-socket-level.md, both of which are the kind of working notes that show how a performance project is actually run.

The project also has a CLAUDE.md and a docs/ directory with the eight documentation pages the README links to, plus an API quickstart described as the essential reference, so the documentation is organised around the API rather than around the features.

The licence change, and what it does to existing code

The licence situation is stated with unusual precision, and it is worth reading carefully because it affects anyone who has vendored the extension or built on it.

Turbo Intruder is licensed under the GNU Affero General Public License v3.0. Releases up to and including 1.62 were published under the Apache License 2.0 and remain available under those terms, so the change to AGPLv3 applies to later versions only. Some parts of the codebase are contributions made under the Apache License 2.0 and stay licensed that way, with the NOTICE file for attribution and LICENSE-APACHE-2.0 for that licence's text.

That last point is the reason a NOTICE file exists in the repository at all, and it is a common pattern for a project that relicensed: existing third-party and contributed code keeps its original terms while the project's own new work moves to the new licence. Anyone who pinned 1.62 or earlier keeps Apache 2.0, and anyone who copied source out of the project into their own tooling needs to check which side of the boundary each file came from.

For a security tool distributed by a vendor, an AGPL is a deliberate choice, and it is a reminder that a Burp extension loaded into a consultant's Burp instance is not a trivial licensing situation.

The release history reflects an older project than the maintenance suggests. The recent releases are 1.2.0 from 2020-08-21, 1.0.19 from 2020-08-20, and 1.0.12 from 2019-08-19, while the last push to the repository was on 2026-10-07, so the working tree is being maintained without the version numbers moving much.

Editorial conclusion

Adopt Turbo Intruder if you need to send requests at a rate Burp Intruder cannot reach, for testing a rate limit, a race condition, or a state machine, and you can work in Python configuration and a raw HTTP stack. Do not adopt it for ordinary request fuzzing, since core Burp Intruder is the better tool there. Verify first which engine you need, because the threaded, Burp, Burp2, and HTTP3 engines differ in what they can express and in what they sacrifice.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. PortSwigger/turbo-intruder on GitHub
3. Project website
4. README
5. Releases