Nuclei Scanner Setup: 13 Steps, 295 Templates [2026]

Open-source vulnerability scanning got a jolt of attention this week after Anthropic launched OSS Scanner on October 8, 2026, an opt-in service that uses Claude models to hunt for bugs in critical open-source repositories. The announcement, part of what Anthropic calls its Cyber Mission, pushed automated vulnerability discovery back into the spotlight. But most teams don’t have access to an invite-only AI scanner, and they don’t need one. They need a scanner they can install today, point at a target, and trust to catch known CVEs before an attacker does.

That’s where Nuclei comes in. Built by ProjectDiscovery, Nuclei is a template-driven vulnerability scanner that runs thousands of community-maintained checks against web apps, APIs, and network services in minutes. It is free, open source (MIT licensed), and sits at roughly 32,000 GitHub stars for the core engine, with the companion nuclei-templates repository carrying about 13,100 stars of its own. On October 5, 2026, that templates repo shipped release v10.5.0, adding 295 new checks and 36 fresh CVE detections in a single update. This guide walks through installing Nuclei, running real scans, wiring it into GitHub Actions, and writing a custom template, with a working demo project at the end.

·

Google · Preferred Sources

Don't miss new tech stories on Google

Add Tech Insider once in the Google app and our stories appear in your news suggestions.

Add Now

What Is Nuclei and Why It Matters in 2026

Nuclei is a command-line scanner that executes YAML-defined templates against a target. Each template describes a specific check: a known CVE, a misconfiguration, an exposed panel, a default credential, or a custom business-logic probe. Instead of writing a scanner that understands every protocol and vulnerability class from scratch, Nuclei separates the engine (fast, written in Go, handles HTTP, DNS, TCP, and more) from the detection logic (templates, written in a plain YAML format anyone can read or contribute). That split is why the project has grown into one of the largest active template libraries in the industry.

The timing matters too. Google Cloud’s September 2026 guidance on hardening CI/CD pipelines pushed teams toward pre-commit scanning and dependency checks that fail a build when an active CVE shows up, and Nuclei fits neatly into that workflow because it runs in seconds against a single target and produces machine-readable output. Separately, a 2024 Linux Foundation survey of open-source maintainers found that only 34% used static application security testing tools and just 33% used infrastructure-as-code security tools, which leaves a lot of exposed surface for a fast, template-based scanner to cover. Snyk’s open-source security survey found a similar gap: just 32% of organizations reported using web application scanners, the category Nuclei’s HTTP templates fall into.

Nuclei isn’t a replacement for a thorough penetration test, and ProjectDiscovery doesn’t market it as one. It is a fast first pass: run it against your own assets, your staging environment, or an authorized target, and it flags known issues in minutes instead of hours. The rest of this guide treats it that way, as a recurring scan you run from a laptop or a CI pipeline, not a one-time audit.

Part of why Nuclei spread so widely is who writes the templates. Unlike a closed scanner where a single vendor decides what gets checked, anyone can submit a pull request to nuclei-templates, and ProjectDiscovery’s maintainers review and merge it. Bug bounty hunters frequently contribute a template the same day a new CVE drops, often before commercial scanners update their own signature feeds. That community velocity is visible in the release cadence: two template releases in a single month is normal, each adding dozens of CVE checks pulled from CISA’s Known Exploited Vulnerabilities catalog and recent disclosures across WordPress, GitLab, SharePoint, and other widely deployed platforms.

That contribution model is also why Nuclei shows up in so many different workflows. Red teams use it for fast initial recon against an engagement’s asset list. Bug bounty researchers run it across a program’s in-scope domains to triage low-hanging fruit before manual testing. Platform and DevSecOps teams bake it into CI/CD so every deploy gets checked against the latest template set automatically. The tool is the same in every case, only the target list and the schedule change.

Set Up a Safe Local Target Before Scanning Anything Real

Before pointing Nuclei at a real domain, it helps to confirm your install, your tags, and your rate-limiting flags all work as expected against a target you fully control. A deliberately vulnerable local app, run in a container on your own machine, is the safest way to do that.

# Run a local, intentionally vulnerable test app
docker run --rm -d -p 3000:3000 bkimminich/juice-shop

# Confirm it's reachable
curl -s -o /dev/null -w "%{http_code}\n" http://localhost:3000

# Scan it with Nuclei
nuclei -u http://localhost:3000 -tags exposure,tech,misconfig

Because this instance runs only on your own machine and never touches a third party’s infrastructure, you can scan it at full speed, test custom templates against it, and get comfortable reading Nuclei’s output format before you ever run it against staging or production. Tear the container down with docker stop once you’re done; there’s no reason to leave a known-vulnerable app running longer than the test requires.

Prerequisites and Version Requirements

Before starting, confirm you have explicit authorization to scan your target. Nuclei sends live HTTP requests, DNS lookups, and in some cases out-of-band callbacks, and running it against systems you don’t own or have written permission to test can violate computer-fraud laws in most jurisdictions. Everything in this tutorial assumes a target you control: a local test app, a staging server, or a domain where you have documented authorization.

• Nuclei: v3.11.1 (latest stable, released August 8, 2026)
• Go: 1.22 or newer, only required for the go install method
• Docker: 24.x or newer, only required for the container method
• Operating system: Linux, macOS, or Windows (via WSL2 recommended)
• Disk space: roughly 500MB for the binary plus the full template set
• Network access: outbound HTTPS to github.com for template updates
• A target: a domain, IP, or local app you’re authorized to scan

You don’t need all four installation methods below, just pick the one that matches your environment. If you’re already running other scanners like OpenVAS for infrastructure-level checks, Nuclei slots in as the fast, templated layer on top for web-facing assets.

Step 1: Choose an Installation Method

Nuclei ships four supported install paths. Go install gives you the newest build straight from source, Homebrew is the fastest path on macOS and Linuxbrew, Docker avoids touching your local Go toolchain entirely, and the prebuilt binary works anywhere curl and tar are available. The table below breaks down when to use each.

Method	Best for	Pros	Cons
go install	Developers with Go already set up	Always current, easy to pin a version	Requires Go toolchain, slower first build
Homebrew	macOS and Linuxbrew users	One command, auto-updates	Can lag a few days behind GitHub releases
Docker	CI/CD runners, isolated environments	No local dependencies, reproducible	Slightly more setup for file I/O
Prebuilt binary	Servers without Go or Docker	Single static binary, fast to deploy	Manual updates

Step 2: Install Nuclei via Go

If you already have Go 1.22+ installed, this is the quickest path to the latest build. Nuclei’s main module lives under the v3 import path now that the project has moved past its v2 series.

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

The binary lands in $(go env GOPATH)/bin, so make sure that directory is on your PATH. To pin a specific release instead of always pulling the newest commit, swap @latest for the version tag, for example @v3.11.1, which keeps your scan results reproducible across machines.

Step 3: Install via Homebrew or Docker

On macOS or Linuxbrew, Homebrew handles the build and keeps Nuclei on your PATH automatically.

brew install nuclei
brew upgrade nuclei   # run periodically to stay current

For CI runners or anyone who’d rather not touch a local Go toolchain, the official Docker image is the cleanest option. Mount a local directory so templates and output files persist outside the container.

docker pull projectdiscovery/nuclei:latest

docker run --rm \
  -v "$PWD:/work" \
  projectdiscovery/nuclei:latest \
  -u https://example.com \
  -t /work/nuclei-templates \
  -jsonl-export /work/results.jsonl

Step 4: Install the Prebuilt Binary

On a server without Go or Docker, grab the release archive that matches your OS and architecture from the project’s GitHub releases page, extract it, and drop the binary somewhere on PATH.

curl -LO https://github.com/projectdiscovery/nuclei/releases/download/v3.11.1/nuclei_3.11.1_linux_amd64.tar.gz
tar -xzf nuclei_3.11.1_linux_amd64.tar.gz
sudo install -m 0755 nuclei /usr/local/bin/nuclei
nuclei -version

Double check the exact archive filename against the release assets before downloading. ProjectDiscovery publishes separate builds for Linux, macOS (Intel and Apple Silicon), and Windows, and the architecture suffix changes accordingly.

Step 5: Verify the Install and Pull the Template Library

Nuclei ships with no templates bundled in the binary itself. The first run downloads the full nuclei-templates repository to a local cache directory, and every scan afterward checks for updates unless you disable that behavior.

nuclei -update-templates
nuclei -templates-version

Run this update step before every scan session. Template releases like v10.5.0 (295 new templates, 36 CVEs, shipped October 5, 2026) and the earlier v10.4.9 (123 new templates, 85 CVEs) land frequently, and a stale cache means missing coverage for anything disclosed in the past few weeks.

Step 6: Run Your First Scan

With templates in place, point Nuclei at a single authorized target. The default run executes the full template set, which is thorough but slow on a first pass, so most people narrow it with tags right away.

# Full scan against one target
nuclei -u https://example.com

# Scan only for exposures and technology fingerprints
nuclei -u https://example.com -tags exposure,tech

# Scan only for known CVEs
nuclei -u https://example.com -tags cve

Expect output that lists each matched finding with a severity tag, template ID, and the matched URL. A clean run against a well-patched target often returns zero findings, which is the point, it’s a fast negative-confirmation tool as much as a bug finder.

Step 7: Scan a List of Targets

Most real-world use involves more than one host. Nuclei reads targets from a plain text file, one per line, which makes it straightforward to feed it output from an asset inventory or a subdomain enumeration tool.

cat > urls.txt << 'EOF'
https://staging.example.com
https://api.example.com
https://admin.example.com
EOF

nuclei -list urls.txt -severity medium,high,critical

The -severity flag filters results so low-signal informational findings don't flood the output. For a first pass on an unfamiliar set of assets, medium-and-up is a reasonable default before tightening further.

Understanding Severity Levels and Template Tags

Nuclei templates carry two separate classification systems, and mixing them up is a common source of confusion for people new to the tool. Severity describes how bad a confirmed finding is: info, low, medium, high, or critical, roughly mirroring CVSS bands. Tags describe what category of check it is: cve for known vulnerability IDs, exposure for things like exposed .git directories or debug panels, misconfig for security-header and configuration problems, tech for technology fingerprinting, and kev for anything present in CISA's Known Exploited Vulnerabilities catalog, meaning it's confirmed as actively exploited in the wild rather than just theoretically risky.

Combining both gives tighter control over what a scan actually checks. A pipeline that only cares about actively exploited, high-impact issues might run -tags cve,kev -severity high,critical, which skips the broader informational sweep entirely and focuses the scan window on the subset of checks most likely to matter for an incident response prioritization call. That pairing also maps cleanly onto how teams already prioritize using the Exploit Prediction Scoring System (EPSS) alongside CVSS, since both approaches try to answer the same underlying question: out of everything theoretically wrong, what's actually worth fixing first.

# List every tag currently available in the template set
nuclei -tl

# Scan using only actively-exploited, high-severity checks
nuclei -u https://example.com -tags cve,kev -severity high,critical

Step 8: Export Results as JSON and SARIF

Human-readable terminal output is fine for a quick check, but any recurring workflow needs structured output you can parse, diff, or feed into another tool. Nuclei supports JSON Lines for general automation and SARIF specifically for GitHub Code Scanning.

# Line-delimited JSON, easy to stream and parse incrementally
nuclei -list urls.txt -jsonl-export results.jsonl

# SARIF, uploadable straight to GitHub's Security tab
nuclei -list urls.txt -sarif-export results.sarif

JSONL is the better pick when you want to pipe results into a SIEM, a Slack bot, or a ticket-creation script. SARIF is the right choice when the goal is surfacing findings natively inside GitHub's pull request and Security tab UI, which is what the CI/CD step below uses.

Step 9: Configure Rate Limiting and Safe Scan Settings

Nuclei's default concurrency is tuned for speed, which is great against infrastructure that can absorb it and a problem against anything fragile. Staging environments, rate-limited APIs, and smaller production services can return 429s, time out, or just produce noisy, inconsistent results if you scan them at full throttle.

nuclei -u https://example.com \
  -rl 10 \
  -c 5 \
  -timeout 10 \
  -retries 1

-rl caps requests per second, -c caps concurrent template threads, -timeout sets the per-request timeout in seconds, and -retries limits retry attempts on failed requests. Start conservative against anything you haven't scanned before, then loosen the limits once you've confirmed the target handles it.

Step 10: Wire Nuclei into GitHub Actions

Running Nuclei by hand works for one-off checks, but the value compounds when it scans automatically on a schedule or on every deploy. The workflow below installs Nuclei, refreshes templates, scans a target stored as a repository variable, and uploads SARIF results to GitHub's Security tab.

name: Nuclei scan

on:
  workflow_dispatch:
  schedule:
    - cron: "0 3 * * 1"

jobs:
  nuclei:
    runs-on: ubuntu-latest
    permissions:
      security-events: write
      contents: read

    steps:
      - name: Install Nuclei
        run: |
          curl -sSfL https://raw.githubusercontent.com/projectdiscovery/nuclei/master/install.sh | sh -s -- -b "$HOME/.local/bin"
          echo "$HOME/.local/bin" >> "$GITHUB_PATH"

      - name: Update templates
        run: nuclei -update-templates

      - name: Scan
        run: |
          nuclei \
            -u "${{ vars.TARGET_URL }}" \
            -severity medium,high,critical \
            -sarif-export nuclei.sarif

      - name: Upload SARIF
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: nuclei.sarif

Set TARGET_URL under the repository's Settings > Secrets and variables > Actions, scoped to a staging asset you're authorized to scan on a schedule. Pin the Nuclei version in production pipelines rather than always pulling the newest build, so a template regression doesn't silently break your CI run.

Step 11: Write and Validate a Custom Template

The built-in template library covers thousands of known issues, but internal tools and homegrown APIs need custom checks. A Nuclei template is a YAML file with an ID, metadata, one or more requests, and matchers that decide whether a finding is real.

id: example-debug-header-check

info:
  name: Example Debug Header Exposure
  author: your-name
  severity: info
  description: Flags a debug header that should not appear outside development.
  tags: misconfig,headers

http:
  - method: GET
    path:
      - "{{BaseURL}}/"

    matchers:
      - type: word
        part: header
        words:
          - "X-Debug-Mode: true"
        case-insensitive: true

Validate the YAML before running it against anything, then execute it directly against a target.

nuclei -validate -t example-debug-header-check.yaml
nuclei -u https://example.com -t example-debug-header-check.yaml

Combine multiple matchers for anything beyond a simple header check. A lone "status 200" matcher produces false positives constantly, since most pages return 200 regardless of the underlying issue. Pair a status check with a word or regex matcher that confirms the actual vulnerable condition, not just that the page loaded.

Step 12: Use Interactsh for Out-of-Band Detection

Some vulnerability classes never produce a visible response in the original request. Blind SSRF, blind command injection, and out-of-band XXE all require a secondary callback to confirm exploitation. Nuclei integrates with Interactsh, ProjectDiscovery's own out-of-band interaction service, to handle exactly that case.

http:
  - method: GET
    path:
      - "{{BaseURL}}/fetch?url={{interactsh-url}}"

    interactsh_protocol:
      - http

    matchers:
      - type: word
        part: interactsh_protocol
        words:
          - "http"

When the template runs, Nuclei generates a unique callback domain, injects it into the request, and watches for a DNS or HTTP hit on that domain. A hit confirms the target made an external request it shouldn't have. Only run OOB templates against systems you're explicitly authorized to test, since a successful hit means the target genuinely reached out to an external address on your behalf.

Step 13: Build a Complete Working Scan Project

Pulling the pieces together, here's a minimal but complete project layout for recurring scans: a target list, a wrapper script, and a GitHub Actions workflow that runs on a schedule and fails the job if critical findings appear.

nuclei-scan-project/
├── targets.txt
├── scan.sh
├── custom-templates/
│   └── example-debug-header-check.yaml
└── .github/workflows/nuclei.yml

#!/usr/bin/env bash
# scan.sh
set -euo pipefail

nuclei -update-templates

nuclei \
  -list targets.txt \
  -t custom-templates/ \
  -severity medium,high,critical \
  -rl 15 -c 10 -timeout 10 -retries 1 \
  -jsonl-export results.jsonl \
  -sarif-export results.sarif

CRITICAL_COUNT=$(grep -c '"severity":"critical"' results.jsonl || true)
if [ "$CRITICAL_COUNT" -gt 0 ]; then
  echo "Found $CRITICAL_COUNT critical findings"
  exit 1
fi

Run ./scan.sh locally to confirm it works against your test target, then drop the GitHub Actions workflow from Step 10 into .github/workflows/nuclei.yml, pointing it at this script instead of a raw nuclei command. That gives you a repeatable, version-controlled scan pipeline that treats a critical finding as a build failure, which is the same pattern Google Cloud's CI/CD hardening guidance recommends for dependency scanning.

Nuclei vs Nikto vs OWASP ZAP vs Burp Suite vs OpenVAS

Nuclei doesn't replace every scanner in a security team's toolkit, it fills a specific niche: fast, deterministic, reusable checks across many assets at once. The table below lays out where it overlaps with other common tools and where it doesn't.

Tool	Primary scope	Cost	Best fit
Nuclei	Template-driven HTTP/DNS/TCP checks, CVEs, misconfigurations	Free, open source	Fast recurring scans across many assets
Nikto	Web server misconfigurations, outdated software, dangerous files	Free, open source	Quick single-server web checks
OWASP ZAP	Proxying, crawling, passive and active application scanning	Free, open source	Interactive app testing and API fuzzing
Burp Suite	Manual pentesting, repeater, intruder, extensions	Community free; Professional and Enterprise paid	Hands-on manual testing workflows
OpenVAS / Greenbone	Network and host-level vulnerability assessment	Open-source core; commercial Greenbone tiers	Broad infrastructure and OS-level coverage

In practice, teams run more than one of these together. Nuclei covers the fast, automatable layer; OpenVAS or Greenbone handles infrastructure-level checks; and Burp or ZAP come out for manual deep-dives when Nuclei flags something worth a closer look. None of them substitute for static analysis tools like Semgrep or infrastructure-as-code scanners like Checkov, which catch issues before code ever reaches a running target.

Cost is the other variable worth spelling out. Nikto, ZAP, OpenVAS, and Nuclei all ship with a genuinely usable free tier that covers the bulk of common use cases, which is a big part of why open-source scanning keeps gaining ground even as commercial platforms add AI-assisted triage and managed services on top. Burp Suite is the outlier here: the free Community edition strips out the automated scanner entirely, so anyone relying on Burp for unattended scanning rather than manual testing needs a Professional license. For a team deciding where to spend a limited security tooling budget, that often means covering the automated layer with Nuclei plus OpenVAS first, then paying for Burp Professional specifically for the manual testing work neither of those tools does well.

Common Pitfalls to Avoid

Most Nuclei mistakes aren't about the tool itself, they're about treating a fast scanner like it's a slow, careful one. The checklist below covers the issues that come up most often among teams adopting Nuclei for the first time, roughly in order of how much damage they can cause if left unaddressed.

• Scanning without authorization. Nuclei's default template set includes active exploitation checks. Running it against a domain you don't own or lack written permission to test can trigger legal exposure even if you find nothing.
• Trusting a single matcher. A template that only checks for an HTTP 200 status will flag almost anything. Always combine a status check with a word, regex, or DSL matcher that confirms the actual vulnerable behavior.
• Forgetting to update templates. Running a six-month-old template cache means missing every CVE disclosed since then, including whatever shipped in the most recent weekly release.
• Full-speed scanning fragile targets. Default concurrency can overwhelm smaller staging environments or rate-limited APIs, producing false negatives from dropped connections rather than a clean result.
• Ignoring WAF interference. A web application firewall can silently rewrite or block requests, making a vulnerable endpoint look clean. Confirm WAF behavior separately before trusting a negative result.
• Treating findings as proof of exploitability. A matched template indicates a likely issue, not confirmed compromise. Version-string matches in particular can misfire against backported security patches.

Troubleshooting Common Nuclei Errors

Most installation and scanning problems trace back to a handful of root causes: PATH misconfiguration, network restrictions blocking template updates, or overly aggressive scan settings tripping a target's own defenses. The table below lists the issues that come up most often in GitHub issues and community forums, along with the fix that resolves each one.

Issue	Likely cause	Fix
"command not found: nuclei"	Binary not on PATH	Add $(go env GOPATH)/bin or /usr/local/bin to PATH
Template update fails or hangs	Blocked outbound access to github.com, or corrupted cache	Check firewall/proxy rules; delete the local template cache and re-run -update-templates
Scan returns zero results unexpectedly	Overly aggressive rate limiting, WAF blocking, or wrong tags filter	Lower -rl and -c, confirm tags with -tags list, test against a known-vulnerable target first
Frequent HTTP 429 responses	Target rate-limiting the scanner	Reduce -rl and -c, add -retries 1, scan during off-peak hours
Custom template fails validation	Malformed YAML indentation or missing required fields	Run nuclei -validate -t yourfile.yaml and fix the reported line
Docker container can't write output files	Volume mount path mismatch or permission issue	Confirm the -v host:/work mapping matches the -jsonl-export path exactly
Interactsh callback never fires	Target has no outbound network access, or the payload wasn't reached	Confirm the vulnerable code path is reachable; test interactsh connectivity independently
Inconsistent results between runs	CDN caching, load-balanced backends, or session state differences	Disable caching headers for test runs, or scan a single backend directly
High false-positive rate on version checks	Vendor backported a fix without changing the version string	Cross-reference with vendor advisories before treating version matches as confirmed

Advanced Tips for Production Use

Once the basics are working, a few adjustments make Nuclei more useful in a real environment rather than a one-off demo. First, pin both the Nuclei binary version and the template release in any automated pipeline. Template releases change weekly, and an unpinned pipeline can start failing (or silently stop detecting something) without a code change on your end to point to.

Second, build an allowlist of tags relevant to your stack instead of running every template every time. A team running a Django API and a React frontend gets far more signal from -tags cve,exposure,misconfig,tech than from a full unfiltered run that also checks for issues in frameworks nobody uses.

Third, feed Nuclei's JSONL output into whatever ticketing or alerting system your team already uses, rather than reading terminal output manually. A small script that diffs this week's results against last week's and opens a ticket only for new findings keeps the signal-to-noise ratio workable as scan frequency increases.

Finally, consider running Nuclei alongside runtime security tooling like Falco and adversary-simulation tools like Atomic Red Team. Nuclei tells you what's exposed before an attacker finds it; runtime tools tell you what's actually happening once something slips through. Layering both gives better coverage than either alone.

Template organization matters more than it seems once a project grows past a handful of custom checks. Keep internal templates in their own directory, separate from the auto-updated community set, so a nuclei -update-templates run never overwrites your custom work. Tag internal templates with something unambiguous like internal-only or company-custom, which makes it trivial to run -tags internal-only in isolation when you only want to check your own business-logic rules rather than the full public library.

Workflow templates are also worth exploring once basic HTTP checks feel routine. Nuclei supports multi-step workflows where one template's output feeds into the conditions for running another, useful for authenticated scanning scenarios where a login request needs to succeed before any subsequent check makes sense. That's a more advanced use case than this guide covers in depth, but it's worth knowing the capability exists before reaching for a heavier tool to solve a problem Nuclei can already handle.

How to Triage Nuclei Findings Without Drowning in Noise

A scan across even a modest set of assets can return dozens of findings, and not every one deserves the same urgency. A workable triage pass starts by separating confirmed CVE matches tagged kev from everything else, since a KEV tag means CISA has documented active exploitation, not just theoretical risk. Those findings jump to the front of the queue regardless of their raw CVSS score, because an actively exploited medium-severity bug is often a more pressing fix than a theoretical critical one nobody has weaponized yet.

After KEV-tagged issues, sort by severity and then by how exposed the affected asset is. A critical finding on an internal admin panel behind VPN carries different urgency than the same finding on a public-facing API. Nuclei's output doesn't make that distinction for you, since it has no visibility into your network topology, so this step still requires a human cross-referencing the finding against an asset inventory. A simple spreadsheet or a lightweight ticketing rule, matched against known public-facing hostnames, closes that gap without much engineering effort.

Finally, before closing out any finding as a false positive, confirm it against the referenced CVE or advisory rather than dismissing it on instinct. A surprising number of "false positives" turn out to be real once someone checks the actual vendor advisory linked in the template's info.reference field, particularly for version-based detections where a backport or a non-standard build tag confused the match. Keeping a short log of confirmed false positives and why they were dismissed also saves the next person on the team from re-investigating the same non-issue during the following week's scan.

Keeping Scans Legal and Scoped

It bears repeating since it's the single most common way people get into trouble with scanners like this: only run Nuclei against assets you own or have explicit written authorization to test. Many organizations maintain a documented scope agreement, and a growing number run formal bug bounty programs with published rules of engagement specifically to make this clear. If you're testing third-party infrastructure, confirm the engagement scope in writing before running anything beyond passive reconnaissance, and keep that documentation on hand for the duration of the engagement.

Frequently Asked Questions

Is Nuclei free to use?

Yes. The Nuclei engine and the nuclei-templates library are both open source and free to use, modify, and redistribute. ProjectDiscovery also offers separate commercial products built on top of the open-source tooling, but the scanner and template set covered in this guide carry no license fee.

How many templates does Nuclei ship with?

The exact count changes every week as the community contributes new checks. The October 5, 2026 release alone (v10.5.0) added 295 new templates and 36 new CVE detections. Run nuclei -update-templates followed by counting the YAML files in your local cache for the exact number on any given day.

Can Nuclei replace Burp Suite or OWASP ZAP?

Not really, they solve different problems. Nuclei is built for fast, repeatable, automatable checks across many targets. Burp and ZAP are built for interactive, manual application testing, intercepting and modifying individual requests as a human tester works through an app. Most security teams use Nuclei for broad recurring coverage and Burp or ZAP for focused manual testing when something needs closer attention.

Does Nuclei work against APIs, not just web pages?

Yes. Nuclei templates support custom headers, request bodies, and multiple HTTP methods, which covers most REST and JSON API testing scenarios. It also has protocol support beyond HTTP, including DNS, TCP, and network-level checks, for targets that aren't purely web-based.

How is Nuclei different from the Anthropic OSS Scanner?

They solve different problems at different scales. Anthropic's OSS Scanner is an invite-only service that uses Claude models to review source code of select critical open-source projects and emails maintainers unreviewed, model-generated bug reports. Nuclei is a self-hosted tool anyone can install and run today against any target they're authorized to test, using a fixed library of community-written detection templates rather than a language model. One requires enrollment and applies to a narrow set of projects; the other you can run from a terminal in the next five minutes.

What output formats does Nuclei support?

Standard terminal output, JSON Lines (-jsonl-export) for general automation and SIEM ingestion, and SARIF (-sarif-export) for direct upload to GitHub's Code Scanning and Security tab. JSON Lines is generally the easier format to stream and parse incrementally in a custom pipeline.

Why do my scans return different results each time?

The most common causes are CDN caching serving stale responses, load-balanced backends with different patch levels behind the same hostname, and template library updates between runs changing what gets checked. Pin your template version for reproducible comparisons, and when possible scan a specific backend directly rather than through a load balancer.

Is it safe to run Nuclei's out-of-band templates in CI?

Only against targets you control and where outbound network calls from the target are expected and authorized. OOB templates work by confirming the target made an external request on command, which means a positive result involves the target genuinely reaching out to an Interactsh domain. Run them deliberately, not as part of an unattended scheduled scan against production unless you've fully accounted for that behavior.

How often should a recurring Nuclei scan run?

There's no universal answer, but weekly is a reasonable default for most teams, with an additional on-demand run triggered after every production deploy. Given that template releases land roughly every one to two weeks and frequently add dozens of new CVE checks, a weekly cadence keeps pace with new coverage without overwhelming a team with duplicate findings for issues that haven't changed since last week's scan.

Can Nuclei scan authenticated parts of an application?

Yes, by supplying session cookies, bearer tokens, or custom headers through a template's headers field, or by using Nuclei's workflow templates to chain a login request ahead of the actual checks. It isn't as fluid as Burp Suite's session handling for deeply stateful applications, but for most API and header-based authentication schemes it works well enough for recurring automated scans.