ActiveScan++ pushes Burp Suite's scanner past its own limits

What ActiveScan++ adds on top of the built-in scanners

ActiveScan++ is a Burp Suite extension, and the project describes it in one line as extending Burp Suite's active and passive scanning capabilities while being designed to add minimal network overhead. The listed target behaviours are specific rather than generic: potential host header attacks covering password reset poisoning, cache poisoning and DNS rebinding, Edge Side Includes, XML input handling, and suspicious input transformation such as 7*7 becoming 49.

The second group is a list of injected probes with known identifiers behind them: blind code injection through expression language, Ruby's open() and Perl's open(), plus named CVEs including CVE-2014-6271, CVE-2014-6278, CVE-2015-2080, CVE-2017-5638, CVE-2017-12629 and CVE-2018-11776.

The distinction that matters is scope. The extension is not another scanner competing with Burp's own; it is a set of additional payloads and detectors that run inside the scan you were going to run anyway, and the README is explicit that the checks are invoked by running a normal active scan.

The Java rewrite and the detections it carried in

The changelog shows a complete rewrite in version 2.0.0, dated 20241202, with the note "Rewrite in Java!". The repository confirms the language: the primary language is Java, the tree holds src/ and build.gradle alongside the Gradle wrapper, and there is no Jython-era source left.

That rewrite is the most important event in the project's history, because earlier versions were scripts. The 1.0.9 entry is telling, since it refers to Jython 2.7 beta and to an error message for anyone foolish enough to try using it. Several entries in the 1.0.x series describe removal of checks that moved into Burp itself, including dynamic code injection and RPO checks, which is a reminder that an extension's value depends on what the host tool has since absorbed.

After the rewrite the entries are terse: 2.0.1 resolved some long-standing false positives, and 2.0.3 addressed Unicode processing issues, with a pointer to research on bypassing character blocklists with unicode overflows. That is the kind of detail worth reading, because a scanner that misses a blocklist bypass is worse than one that reports noise.

Passive issues that only appear while a request is being fuzzed

The most interesting line in the feature list is the one about passive-scanner issues that occur only during fuzzing, which pairs with the suggestion to install the Error Message Checks extension for maximum effectiveness.

The mechanism is a feedback loop. A payload changes the application's behaviour, and the resulting response contains an error message or an unusual status that a passive scanner would not have flagged on its own. An earlier changelog entry, 1.0.12, describes triggering a fresh passive scan when an alternative code path is identified, and notes that this combines well with the Error Message Checks extension.

The other entry in this family is 1.0.24, which devised a check with no CVE behind it, referring to research on smashing the state machine. Detecting state machine abuse is the kind of check that only makes sense once the scanner is already perturbing the request.

The honest limit here is that these detections inherit the extension's traffic. The design goal of minimal network overhead is stated, not measured, and the README gives no configuration for tuning the volume of injected traffic, so a target that rate-limits will change how these checks behave.

Installing the jar into Burp Suite by hand

There is no package manager step in the documentation. Installation is manual and runs through the Burp user interface, and the file you need is the built jar:

1. 'Extensions'->'Installed'->'Add
2. Click 'Select file'
3. Choose build/libs/active-scan-plus-plus-all.jar

The requirement that comes before all of this is a licence: the documentation states Burp Suite Professional or Enterprise, latest stable version. The extension is therefore never useful on its own, since it has no interface and no scanning engine of its own.

The usage note is short because the design is short. To invoke the checks, run a normal active scan. There is no separate mode, no configuration file and no documented command line entry, so if you want the checks you have to scan actively and accept the traffic that implies.

Two jar files, one extension, and a build step nobody documents

The repository tree lists bulkScan-all.jar at the top level, while the manual installation instructions point at build/libs/active-scan-plus-plus-all.jar. Those are different file names in different locations, and the documentation does not say which one to load or how they relate. If you are picking a file to install, that ambiguity is the first thing to resolve.

The repository also carries gradlew and gradlew.bat alongside build.gradle, so a source build path exists, but the README documents no build command and no wrapper invocation. The instructions assume you already have a jar, which means the build is effectively an undocumented prerequisite for following them exactly.

Two other top-level entries are worth noting. BappManifest.bmf and BappDescription.html are the metadata files for the Burp Suite BApp Store listing, which tells you the extension is published as a BApp as well as being loadable by hand. The last push to the repository was on 2026-09-21, so the tree is being touched even though the tagged release visible in the repository list is 2.0.0, published on 2024-12-03.

Where ActiveScan++ is the wrong tool

The clearest case for not using it is a Burp Community user. The stated requirement is Professional or Enterprise, and nothing in the documentation offers a free path, so a team on the free edition gets none of these checks.

The second case is a passive-only review. Every check is invoked by an active scan, so a workflow built on browsing and passive analysis gains nothing from the extension, and a policy that forbids active probing rules it out entirely.

The third case is a target where fuzzing is not acceptable, such as a third-party production service under a strict scope. The plugin's value comes from injecting payloads, so its usefulness scales directly with your authorisation to send them.

There is also a maintenance question. A Java rewrite in December 2024, a changelog entry for 2.0.3 in January 2025, and a repository whose most recent tagged release is 2.0.0 leave a gap between the code on disk and the version history you can point to in a report. The README does not document compatibility with specific Burp versions, so the safest check is to load the extension on a recent stable Burp and confirm the checks still fire.

Apache-2.0 terms and a release trail that stops at the rewrite

The project is released under the Apache-2.0 licence, with the LICENSE file at the repository root. Those terms permit use and modification inside a commercial product, including in a consultancy deliverable, which matters for a tool whose output tends to land in client reports.

The release trail deserves a careful read. The repository's release list shows a single entry, 2.0.0 with the name ActiveScan++ Java Rewrite, published on 2024-12-03. The changelog in the documentation tells a longer story, dating the rewrite 20241202 and then listing 2.0.1 on 20241210 and 2.0.3 on 20250123. So the tag history and the changelog do not line up, and a team that pins to the released jar may be behind the documented fixes for Unicode handling and false positives.

The last push was on 2026-09-21, so the repository is not archived and is not stale, but no tagged release is attached to that work. For a plugin that loads into a licensed tool, that combination, live repository with a released artefact that trails it, is the detail to plan around rather than a sign of neglect.

Editorial conclusion

ActiveScan++ earns its place in a Burp Professional or Enterprise workflow where the target mixes XML, templating and a reverse proxy, since host header poisoning, ESI and expression language probes are exactly the classes the core scanner does not chase on its own. It does not help a team without a Burp licence, and it adds nothing to a passive-only review because every check fires during an active scan. Before loading it, confirm your Burp version is a recent stable release, decide whether the two jar files in the repository are the same build, and run one request through a scan to see how much traffic the added checks generate on your target.

Frequently asked questions

Official sources

1. albinowax/ActiveScanPlusPlus on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases