projectdiscovery/nuclei-burp-plugin for Faster Nuclei Template Authoring

Why projectdiscovery/nuclei-burp-plugin Matters Inside Burp Suite

This plugin addresses a narrow point in a security testing workflow: creating Nuclei templates from HTTP traffic already visible in Burp Suite. Without it, a tester may need to copy response content or request structures into a separate editor and construct the surrounding YAML by hand. The plugin turns selections from Proxy history, Repeater, and Intruder into an initial template while retaining links to the traffic that produced them.

It is intended for testers already using Burp Suite and Nuclei, not as a separate vulnerability scanner or a complete replacement for either product. Burp supplies the observed requests and responses. The plugin supplies generation, editing, command construction, and execution controls. Nuclei remains the executable scanning engine, and the documentation states that the plugin uses an absolute path to the Nuclei binary and template file.

The integration also works with Burp Suite Community because the README explicitly says that Burp Suite Professional is not required. That removes one common adoption concern, but it does not remove local dependencies. The user still needs a usable Nuclei installation and a Burp process that can locate its executable.

This is an authoring aid rather than an automatic correctness checker. A generated Word or Binary matcher captures selected text, and the plugin automatically adds a matcher for the response status code. Those choices provide a useful starting point, but the README does not claim that every generated template is complete, safe to run broadly, or ready for publication.

From Selected HTTP Data to a Nuclei Template

The plugin's main mechanism is contextual selection. A tester highlights content in a response shown in Proxy history or Repeater, then uses the plugin to create matcher material from that selection. Multi-line selections are split into separate words for readability. If the selection includes non-ASCII characters, the plugin creates a Binary matcher instead. It also uses the selection context to set the `part` field when the text came from a request header or body.

Every generated template includes a `Status` matcher based on the selected response's HTTP status code. This means the initial template is not limited to the highlighted words or bytes. It also records a basic response property from the same exchange. The README does not describe heuristic tuning of the status condition or explain how ambiguous selections are rejected, so those details should be checked in the generated YAML before execution.

Previously generated templates can be expanded. Selecting another response fragment allows a tester to add matchers and requests rather than replacing the original file. For a vulnerability tracked as a CVE, the template context menu also provides `Add` and `Classification` controls for entering template information. This supports incremental authoring.

Request generation follows a separate path. In Intruder, selected payload positions can produce request templates for `Battering ram`, `Pitchfork`, or `Cluster bomb`. A selected HTTP request from Proxy or Repeater defaults to `Battering ram`. Multiple proxy items can be selected when a template needs multiple requests. These are template structures based on existing traffic, not evidence that the plugin can design a complete detection strategy by itself.

Executing Templates Through the Generated Nuclei Command

The plugin can execute the current template and display output in its own window. According to the README, it constructs the CLI command automatically from three concrete values: the absolute path to the Nuclei binary, the absolute path to the template, and target information extracted from the selected HTTP request. This removes some manual path assembly, but it also means executable discovery is part of the adoption boundary.

During installation, the plugin searches the process environment `PATH` for the Nuclei binary. The documentation warns that the Burp Suite application binary may not inherit the current user's `PATH`, whereas the stand-alone BurpSuite jar may do so. A user can therefore have a working Nuclei command in a terminal and still have template execution fail inside Burp. The project does not document a fallback executable search beyond the stated configuration detection, so this behavior should be verified before importing important work.

The command history contains unique executed commands and can be searched and run again during the current Burp session. The README calls this a current-session history, so it should not be treated as a durable audit log. Pressing `Ctrl + R` opens CLI flag filtering and completion support. Generated command text should still be reviewed, particularly the target and template path, before running it.

The editor also tracks a template after it is moved. If the file is saved to a new location, the displayed template path is updated. The README recommends `template-id` as the filename. That convention can simplify identification, but the documentation does not define a filename validation rule or publish templates for you.

Installing projectdiscovery/nuclei-burp-plugin and Starting a Template

The project documents two installation routes. The quickest documented route is the BApp Store. In Burp Suite, open `Extender`, select the `BApp Store` tab, search for `Nuclei Template Generator Plugin`, and click `Install`. This route installs a published plugin build without building the repository.

For a local build, the README requires Maven `3.x` and Java `11+`. On macOS, its documented dependency command is:

brew install mvn openjdk@11

After the dependencies are available, build the plugin with:

mvn clean package -DskipTests

The README does not specify the resulting JAR filename or exact output directory, so those values should be read from the completed Maven build rather than assumed. To load the artifact, open Burp Suite's `Extender`, go to `Extensions`, click `Add`, leave `Extension Type` set to `Java`, and select the built `.jar` file.

A first use should stay deliberately narrow. Load an HTTP response in Proxy history or Repeater, select a short response fragment, and invoke the plugin's template generation action. The generated view should contain a Word matcher, or a Binary matcher if the selection contains non-ASCII characters, plus the automatic `Status` matcher. Save it using `Ctrl + S`; the documentation recommends the template ID as the filename. Inspect the YAML before execution, especially the `part` value and target URL. `Ctrl + Enter` executes the current template, while `Ctrl + R` exposes CLI argument help.

The README documents installation of the Burp plugin but does not provide a Nuclei installation command. Nuclei availability and configuration therefore remain prerequisites that the reader must resolve separately.

Editor Assistance, Configuration Boundaries, and Workflow Limits

The editor includes experimental, non-contextual YAML property and value auto-completion based on Nuclei's JSON schema. It also highlights YAML properties that correspond to schema terms. The word "experimental" matters here. The feature assists with valid reserved terms, but the README does not explain validation strength, schema version tracking, or whether context-dependent combinations are checked.

Most actions have documented shortcuts, including opening Nuclei template documentation with `F1`, moving between the editor and CLI field, saving, changing font size, and switching tabs. These controls can make repeated template work faster without hiding the generated YAML. A dedicated template window or an embedded view under `Generator` in the Nuclei tab can be selected according to the user's preference.

Configuration is partly inferred. The target template path is calculated from the default Nuclei template directory configured under `<USER_HOME>/.config/nuclei/.templates-config.json`, and the logged-in operating-system user name becomes the default template author. Automatic detection is convenient, but defaults derived from one account may not match a shared workstation, a CI identity, or a publishing convention.

The plugin does not document proxy configuration for Nuclei, rate-limit defaults, authentication settings, severity policies, or a rollback procedure. Those omissions do not prove those controls are absent from every generated command, but they mean this README is insufficient for assessing safe execution at scale. The plugin also remains Burp-specific. There is no documented headless mode, so a workflow built around unattended template editing would not follow directly from the documented feature set.

Release Cadence, Build Maintenance, and the MIT Boundary

The repository is not archived. Its last push was on 2026-09-22, and release `v1.1.4` was published on 2026-09-14. That is recent activity, but this review does not characterize the project as actively maintained beyond those dated facts. The preceding listed releases, `v1.1.3` and `v1.1.2`, date from 2024-04-08 and 2023-11-07, so the release history is not uniformly frequent.

The source uses Maven, as shown by `pom.xml` and the documented `mvn clean package -DskipTests` command. Maintaining a private build therefore carries the ordinary cost of keeping Maven, Java, Burp Suite, and a compatible Nuclei binary available. The README does not state the supported Burp Suite range, supported operating systems beyond a macOS dependency example, or Nuclei compatibility matrix. Those are material upgrade checks for an integration that constructs executable commands.

The repository identifies the project as licensed under MIT. That permits use and modification under the license's conditions, including preservation of its copyright and license notice. It does not grant rights in Burp Suite, Nuclei, or other separately distributed software. The README does not provide legal interpretation of how the plugin's MIT terms interact with those dependencies, so organizations should review the actual `LICENSE` file and their own distribution obligations rather than infer them from this feature summary.

Compared with manual Nuclei authoring, the plugin's difference is operational rather than conceptual. The manual approach copies HTTP material into an external YAML editor and constructs commands in a shell. This plugin keeps selection, template edits, path management, command assembly, execution, and current-session command reuse inside Burp Suite. That saves repeated transcription for interactive testers, but it adds a Burp-to-Nuclei dependency and gives up a documented standalone editing path.

Editorial conclusion

Burp Suite users who already work with Nuclei and repeatedly turn observed HTTP responses into templates should evaluate this plugin after confirming that Burp can locate the Nuclei binary and that its generated YAML matches the intended validation logic. Teams that need a standalone template editor, do not use Burp, or cannot permit Burp to invoke a local Nuclei command should keep the manual workflow instead. The first project-specific check is a trial template containing only the selected response evidence and expected Nuclei execution behavior.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. projectdiscovery/nuclei-burp-plugin on GitHub
4. README
5. Releases