The PortSwigger bambdas repository collects the scripts that extend Burp Suite

What a Bambda is, and the five things you can build with one

Bambdas are scripts that run in supported Burp tools, and the README's framing is that they enable you to quickly personalize Burp Suite by creating five kinds of thing.

Table filters dynamically filter tables in Burp. Table columns add custom table columns to surface important data. Repeater custom actions extract, transform, and analyze data in Burp Repeater. Match and replace rules replace parts of HTTP and WebSocket messages as they pass through the proxy. And custom scan checks let you create your own active and passive scan checks.

That last category has a wrinkle worth knowing before you start. The bambdas repository contains checks written in Java, and for checks written in PortSwigger's own BChecks language, the README points you at the separate BChecks repository. So there are two languages and two repositories, and the split is not arbitrary: BChecks is PortSwigger's own DSL for scanner checks, while the bambdas repository holds the Java implementations.

The edition split is the other thing to know up front. You can use table filter scripts in both Burp Suite Community Edition and Burp Suite Professional, but all other scripts require Burp Suite Professional.

So the practical picture is that Community Edition users get one of the five categories, and the other four are Professional-only. That is a reasonable division given that filters are the most broadly useful of the set, and it means the repository is still worth reading if you are on the free edition.

The repository is described as the official Bambda scripts repository from PortSwigger, containing scripts developed both by PortSwigger and by the community. The primary language is Java, the licence is LGPL-3.0, and the last push was on 2026-10-13.

How the repository is organised

The top-level entries map almost one to one onto the script types, which makes the repository browsable rather than something you search blindly.

There is a Filter/ directory for table filters, and inside it the documentation links separate subdirectories by the view they apply to: HTTP history under Filter/Proxy/HTTP, WebSockets history under Filter/Proxy/WS, the site map under Filter/SiteMap, and the logger view filter under Filter/Logger/View.

The CustomColumn/ directory follows the same shape, with HTTP history, WebSockets history and the logger each in their own directory.

Then the three categories that are not table-oriented. CustomAction/ holds the Repeater custom actions, MatchAndReplace/ holds the match and replace rules, and CustomScanChecks/ holds the Java scan checks.

The proxy, site map and logger naming is a detail that saves time when you are looking for something. Knowing that the HTTP history filter lives under a Proxy path tells you that the scripts there receive messages that came through the proxy, which is a different set of assumptions from the site map filters, which are working on a view Burp built itself.

Alongside the script directories there is a CONTRIBUTING.md, a CODE_OF_CONDUCT.md, a LICENSE, and a BambdaChecker-1.5.jar at the root, which appears to be the tool used to validate submitted scripts.

The distinction between the filter and custom column directories is the one to hold on to, because they look similar and do different jobs. A filter decides which rows you see. A column decides what appears in a row. The same underlying data, two different jobs, and a script written for one does not generally work as the other.

Importing scripts into Burp

The import procedure is described as a numbered sequence, and it is short enough that there is nothing to get wrong if you follow it.

Download scripts from the repo, or download the full repo as a ZIP file. If using the ZIP file, extract its contents. In Burp, go to Extensions and then Bambda library. Click Import, and the Import scripts dialog opens. Select the .bambda files or the extracted ZIP folder. Click Open.

Burp adds the selected files to your Bambda library. If you select a folder, Burp automatically finds and includes any .bambda files within it and its subfolders.

That last behaviour is why downloading the whole repository as a ZIP is a reasonable first move. The folder import walks subfolders, so pointing Burp at the extracted Filter directory gets you every filter in one step, and the same is true of CustomColumn and the rest.

Once imported, the documentation notes you can load your scripts across Burp and in different projects as required. That is the property that makes the Bambda library worth curating rather than treating as a scratchpad: a script you wrote once for one engagement is available in the next one.

The warning at the end of that section is the most important line in the guide. Scripts can run arbitrary code. For security reasons, please be cautious when importing and using scripts.

That is not boilerplate. A Bambda runs inside the proxy, which means it runs inside the same process that holds your session cookies and your credentials for every target you are testing, and a script from an unknown source is code with access to all of it. The documentation's framing of the repository as official and community-contributed does not change what a script is once it is imported.

For updates, the answer is that you simply re-import them, and Burp prompts you to confirm whether to overwrite existing scripts. There is a documentation page on updating your scripts for the detailed version.

Contributing, and the resources for writing your own

The contributing section splits by how experienced you are, which is a useful sign that the process is genuinely used by newcomers.

If you are new to contributing, the README points at a step-by-step guide on submitting scripts to the GitHub repository. If you have contributed before, there is a contributing quick reference guide to refresh the process and guidelines. And in both cases you are asked to be familiar with and respect the Code of Conduct when making submissions.

The resources section is larger than the contributing section and is worth scanning even if you never contribute, because it contains the learning content for writing scripts yourself.

For learning about the script types there is the Bambdas documentation with detailed information on all script types and where they can be used, plus a set of short videos: a quick introduction with examples of filter scripts, an overview of table filter scripts, an overview of creating custom table column scripts, a video on using custom actions to customize Burp Repeater, and a video on storing and managing your scripts in the Bambda library.

For writing your own scripts there is the creating scripts documentation, described as guidance on creating scripts including reference material and examples, and a video on using the Bambda output console to test and debug scripts. That last one is the practical tip for anyone starting out, since a script that misbehaves in Burp without an output console is hard to debug.

Two resources show the scripts in use rather than in isolation. There is a blog post by James Kettle on using filter scripts during testing, which is the clearest explanation of why a filter is worth writing, and a Web Security Academy lab on limit overrun race conditions that uses a custom action, so the script is load-bearing in the exercise rather than incidental to it.

One thing the repository does not do is provide a Java API for the scripts themselves. The bambdas repository holds .bambda files, and the custom scan checks are written in Java and need the BambdaChecker jar, but the general scripting model for the other categories is the one described in the PortSwigger documentation rather than something this repository teaches. A newcomer looking for a Java SDK in this repository will not find one.

Where the bambdas repository fits, and where it stops

The comparison worth making is with writing the script yourself and with a general Burp extension.

Against writing the script yourself, the difference is what the script does for other people. A filter you write for one engagement is useful to you for the next one and to nobody else, whereas a filter contributed here is available to every tester who imports it. The collection has the same property as a curated package list, and the value grows with the number of contributors, which is why the documentation is explicit that the collection contains scripts developed both by PortSwigger and by the community.

Against a general Burp extension, the difference is the surface area. A Bambda is a script that hooks into a specific place in the UI or the proxy, and it runs in the same process as Burp but without the work of building and shipping a Burp extension with its own UI, its own update mechanism and its own licensing story. That is a much lower bar for a one-off improvement, and it is also the reason a Bambda cannot do things that need to run outside Burp.

The limits are worth stating plainly. The five script types are a closed set, and a need that does not fit any of them needs a real extension instead. Everything except table filters requires the Professional edition, which puts a licence cost on the other four categories for anyone outside a commercial engagement. And the scripts can run arbitrary code, so importing from this repository, or from any repository, is a decision that has to be made deliberately rather than by reflex.

There is a maintenance dimension as well. The repository has no tagged releases, so there is no tagged version and no changelog to track; the last push was on 2026-10-13 and the repository is not archived. The scripts are imported as individual files, so the way to keep them current is to re-import from the repository, and the guide says as much.

For a tester who wants to reuse other people's work rather than write their own, this repository is the place to look, and the import folder behaviour makes it cheap to try a whole category at once.

Editorial conclusion

The bambdas repository suits a security tester who has hit the same tedious manual step many times over, whether that is filtering a large HTTP history, adding a column, or rewriting a request in Repeater, and the import step is deliberately simple so that a script can be dropped into the Bambda library in seconds. It is the wrong tool if you need something not covered by the five script types, since a Bambda is not a general Burp extension, and it is the wrong tool if you cannot accept the risk of running code from a repository, which the README warns about explicitly. Before you import anything, read the scripts can run arbitrary code warning, and check the Community Edition limitation, because only table filters work outside the Professional edition.

Frequently asked questions

Official sources

1. Issues
2. License: LGPL-3.0
3. PortSwigger/bambdas on GitHub
4. README