From Zero to Exploit Detection: A Practical Guide to Nuclei Templates for Pen Testing

Nuclei is a Go based scanner that runs YAML defined templates against targets to detect vulnerabilities. Install the binary, update the community template repository regularly, and filter scans by severity or tags like WordPress. For WordPress engagements, run reconnaissance, then exposure templates, then CVE tagged templates for identified plugins.

Vulnerability scanning used to mean choosing between a handful of expensive commercial scanners or writing your own scripts for every check you cared about. Nuclei changed that calculation. It is an open source scanning engine built by ProjectDiscovery that runs YAML defined templates against targets, and the template library has grown into one of the largest crowdsourced collections of vulnerability checks anywhere. This post walks through Nuclei from first install to writing your own templates, with a specific section on WordPress because so many real world engagements involve a WordPress stack somewhere in scope.

A note before any of this. Every example below assumes you are testing infrastructure you own, or infrastructure you have explicit written authorization to test. Scanning systems without permission is illegal in most jurisdictions regardless of intent. Set up a local lab (a Docker container running a vulnerable WordPress install is the easiest starting point) before pointing anything at a live target.

1. What Nuclei Actually Is

Nuclei is a Go based scanner that takes a template, a small YAML file describing a request and a matching condition, and runs it against one or more targets. A template might send an HTTP request to a known plugin path and check whether the response contains a version string tied to a disclosed vulnerability. Another might send a crafted payload and look for evidence of command injection in the response timing or content.

The engine is fast and well maintained, but Nuclei’s real advantage is its template ecosystem. New templates frequently appear soon after important vulnerabilities are disclosed, giving testers a rapidly updated library of reusable detection logic. Instead of rebuilding a check for every disclosure, you can consume, inspect, validate, and adapt an existing template.

It is worth being precise about what a template result actually tells you. Nuclei templates range from passive checks, a version string in a response header, a readme file confirming a plugin is installed, through to requests that actively exercise a vulnerable code path, such as an injection payload that returns evidence of execution. A positive match does not automatically mean the target is exploitable, and it does not automatically mean the request was harmless. Before running a template against production infrastructure, understand what that specific template actually does, not just what category it falls under.

2. Installing Nuclei

Nuclei is a single Go binary with no runtime dependencies once compiled. The easiest path for most people is the prebuilt binary, since it needs nothing installed beforehand. Download the release for your platform from ProjectDiscovery’s GitHub releases page, unzip it, and place the nuclei binary somewhere on your path.

Swap the filename for the macOS or Windows release if you are on a different platform. Confirm it is working with:

nuclei -version

If you already have a Go toolchain set up and prefer to build from source, go install works just as well.

go install github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest

If Go is not already on your machine and you want to go that route anyway, install it first from go.dev/dl, or through your package manager (apt install golang on Debian and Ubuntu, brew install go on macOS).

Once Nuclei is installed by either method, pull the current template set:

nuclei -update-templates

This downloads the community template repository into a local directory, usually under your home folder. Nuclei also checks for new community template releases automatically each time it runs and downloads the latest version when one is available, so in normal use the installed template set stays current without a separate scheduled job. You can still force an update explicitly with nuclei -update-templates, which is worth doing before a controlled assessment so you know exactly which template version was in use.

Treat templates as executable security logic rather than passive signatures. A template does not just detect, it sends a request, and depending on the template that request may exercise the vulnerable behaviour rather than merely observe it. Before running newly downloaded or unfamiliar templates against sensitive systems, review what requests they send and what their match logic is actually designed to trigger.

3. Understanding Template Structure

A basic template has four parts: metadata (id, name, author, severity), the request definition, matchers that decide whether the response indicates a finding, and optionally extractors that pull data out of the response for reporting.

Here is a simplified example checking for an exposed .env file, a common misconfiguration that leaks database credentials and API keys:

id: exposed-env-file

info:
  name: Exposed .env File
  author: example
  severity: high
  description: Detects publicly accessible .env configuration files

http:
  - method: GET
    path:
      - "{{BaseURL}}/.env"
    matchers:
      - type: word
        words:
          - "DB_PASSWORD"
          - "APP_KEY"
        condition: or

Read that template top to bottom and you already understand the mental model for most of the library. Request goes out, matcher checks the response, finding gets reported if the matcher condition is true.

4. Running Your First Scan

Point Nuclei at a single target with default settings:

Running Nuclei without narrowing the template selection can generate a broad scan against a single host. For a faster and more useful first pass, explicitly filter by severity, tags, or technology so you start with the findings most relevant to the target.

Scanning a list of targets rather than a single host is just as simple:

nuclei -l targets.txt -severity critical,high,medium -o results.txt

Filtering by tag is often more useful than filtering by severity alone, particularly once you know what kind of stack you are dealing with. Tags include things like cve, exposure, misconfig, takeover, and technology specific tags such as wordpress, apache, or nginx.

5. Scanning WordPress Sites

WordPress remains one of the most common platforms encountered on engagements, and its plugin ecosystem is the primary attack surface. Nuclei ships with a large set of WordPress specific templates covering plugin vulnerabilities, theme vulnerabilities, exposed configuration files, and core misconfigurations.

A typical WordPress focused scan looks like this:

Depending on the current template set, this can include checks for exposed WordPress configuration backups, debug files, XML RPC related issues, user enumeration, and known vulnerabilities in popular plugins and themes such as older releases of Elementor, WooCommerce, or Contact Form 7.

A more targeted workflow for WordPress engagements usually runs in three passes. It is worth treating this as a named framework rather than three loose steps, because the order matters and skipping straight to pass three is where most wasted scan time comes from.

Pass 1: Discover. Identify the stack, the theme, and the installed plugins with their versions before running any exploit oriented templates. Firing hundreds of plugin specific checks against a site that is not running those plugins wastes time and generates noise. A tool like WPScan or even manual inspection of page source for plugin references narrows the field considerably. Nuclei also supports -as, an automatic scan option that uses technology detection to map the observed stack to relevant template tags on its own. For WordPress specifically, explicit reconnaissance with something like WPScan is still worth doing alongside it, since knowing exactly which plugins and versions are present makes the following passes far more targeted than technology detection alone.

Pass 2: Expose. Run the exposure and misconfiguration templates. These catch the highest value low effort findings, exposed backup files, open debug logs, directory listings enabled on wp-content/uploads, and default credentials left on staging installs.

Comma separated tags like this are read as an OR across the listed tags, not a strict AND with WordPress. If you want to express a more precise condition, such as WordPress together with either exposure or misconfig, use the template condition flag instead.

Pass 3: Validate. Run the CVE tagged templates for the specific plugins identified in the discovery pass. If you know the target runs an older version of a specific plugin, you can filter templates by name rather than running the entire WordPress category.

The same Boolean precision applies here. If you specifically want WordPress and CVE tagged templates together rather than either one broadly, -tc makes that intent explicit.

Once you know the specific plugin and version in play, you can narrow further by template name or ID rather than by relying on the repository’s current directory layout, which shifts over time as the project reorganises.

6. A Worked Example Against a Lab Install

Assume you have spun up a deliberately vulnerable WordPress instance locally, something like the WPScan vulnerable test images or a manually configured install running an outdated plugin with a known SQL injection disclosure. The workflow looks like this.

Run reconnaissance first to confirm the plugin and version.

This can identify WordPress and other technologies exposed by the target. Depending on what the application reveals, it may also surface information useful for identifying the theme, plugins, or versions in play, though it is not a guaranteed enumeration of any of those.

Run the targeted WordPress exposure sweep.

If the lab install includes a deliberately exposed wp-config.php.bak file, this pass surfaces it immediately with the file contents matched against database credential patterns.

Run the CVE sweep for the specific plugin version identified.

Nuclei reports each finding with the template id, severity, matched URL, and often the specific string or pattern that triggered the match, which gives you an excellent starting point for verification and reporting. You should still manually verify before reporting a finding as confirmed rather than merely detected, since automated matchers occasionally produce false positives on custom error pages or heavily modified installs.

7. Writing a Custom Template

The community library will not cover everything, particularly internal applications or client specific configurations. Writing a template for a finding you have already manually confirmed is one of the more useful habits a pen tester can build, since it turns a one time manual check into something repeatable across future engagements.

Say you have manually confirmed an internal admin panel is reachable without authentication at a predictable path. A template capturing that looks like this:

id: internal-admin-panel-exposed

info:
  name: Internal Admin Panel Reachable Without Auth
  author: your-name
  severity: high
  tags: exposure,panel

http:
  - method: GET
    path:
      - "{{BaseURL}}/admin/dashboard"
    matchers:
      - type: word
        words:
          - "Welcome, Administrator"
        part: body
      - type: status
        status:
          - 200
    matchers-condition: and

Test any custom template against a known vulnerable target and a known safe target before relying on it, to confirm the matcher logic is specific enough to avoid false positives on unrelated pages that happen to return a 200 status.

Before that field test, validate the template itself with Nuclei’s built in linter. This catches YAML syntax errors and structural mistakes without needing a live target at all.

nuclei -validate -t internal-admin-panel-exposed.yaml

Run this as a habit every time you write or edit a template. Validation catches malformed or structurally invalid templates before an engagement, where a skipped or unloaded check could otherwise create a false sense of coverage.

A template is only as good as its matcher, and this is where a lot of custom templates fall short in practice. A single common string or a bare 200 status code is rarely enough to prove a vulnerability, since plenty of unrelated pages can satisfy that same loose condition. Stronger templates combine independent signals, a specific status code together with distinctive response content, a version extracted from a header, or behaviour that only a vulnerable target would exhibit, so that the combination is what confirms the finding rather than any one weak signal on its own. When you test a new template, run it against a patched version of the same application and against a similar but unrelated application as well as the vulnerable target, not just the vulnerable target alone. A matcher that only gets tested against the positive case is the one most likely to produce false positives once it meets a real engagement.

8. Keeping Scans Clean

A default Nuclei run against a broad scope can generate more noise than signal if you do not tune it. A few habits keep results usable rather than overwhelming.

Control concurrency and request rate deliberately rather than accepting the defaults, particularly against production systems where an aggressive scan can degrade performance for real users. The -c flag sets concurrent templates and -rate-limit caps requests per second.

Exclude intrusive templates when the goal is detection rather than active exploitation. Templates tagged dos or fuzz can affect target stability, and they are worth running only with explicit client sign off and a clear understanding of the risk.

Do not treat excluding those tags as a safety guarantee. Template tags are metadata supplied by the template author, not a verified safety boundary, so review unfamiliar templates before running them against sensitive production systems regardless of how they are tagged.

Output structured results rather than plain text once you are running Nuclei as part of a pipeline rather than a one time check. JSON output feeds cleanly into reporting tools or a ticketing system.

Severity describes potential impact, not certainty. A critical severity template with a loose matcher may deserve more verification than a medium severity template with several independent, tightly scoped match conditions. Read the matcher logic in a template before trusting its severity label at face value.

9. Building This Into a Repeatable Workflow

The real payoff from Nuclei comes from treating it as part of a pipeline rather than a one off tool. A workflow that has served well across engagements looks something like this.

Keep template freshness explicit in your workflow. Nuclei normally checks for community template updates automatically, but for controlled engagements it is still worth updating deliberately before the assessment and recording the template version used, rather than assuming the version on disk at scan time.

Separate reconnaissance from exploitation in every scan. Fingerprint the stack first, filter templates based on what you found, then run targeted sweeps rather than the full library against every target. This keeps scan time reasonable and keeps false positive rates lower.

Feed confirmed findings back into your own template library. Over enough engagements, an internal set of custom templates for recurring findings, that internal admin panel pattern, a specific misconfigured header, a client specific default credential set, becomes genuinely valuable and saves substantial manual verification time on future assessments.

10. Where This Fits in a Broader Assessment

Nuclei is a detection tool, not a complete pen testing methodology. It excels at catching known vulnerabilities, exposed files, and common misconfigurations quickly across a large scope. It does not replace manual testing for business logic flaws, authentication bypass chains that require multiple steps, or anything requiring understanding of how a specific application is meant to behave. Treat it as the fast first pass that clears the low hanging findings so the bulk of manual testing time goes toward the vulnerabilities that automated tooling cannot find.

For WordPress specifically, that division of labor matters. Automated scanning will catch known plugin CVEs and common exposures quickly. It will not catch a poorly implemented custom plugin with a business logic flaw specific to that client’s build, and that gap is exactly where manual review earns its place in the engagement.