Nuclei Vulnerability Scanner Guide for Defenders

When a vulnerability lands in the CISA Known Exploited Vulnerabilities catalogue, the question "are we exposed?" needs an answer in hours, and full authenticated scan cycles rarely deliver that. Nuclei, an open source scanner from ProjectDiscovery, answers narrow questions quickly by running small YAML templates that each check for one specific condition. This guide explains what Nuclei does, where it fits in a defender's toolkit, how to run it safely and with authorisation, and how it compares with the alternatives. It is for vulnerability management, attack surface and application security teams who want to use template-based scanning without creating new risk. Scanning programme design is covered in the Vulnerability Scanning Guide; this page focuses on the tool.

Key takeaways

Nuclei verifies, it does not inventory. Each template tests one condition, which makes it fast and precise for known issues, but it does not replace an authenticated vulnerability scanner or an asset inventory.
KEV coverage is its strongest defender use. The community templates repository tags templates for actively exploited vulnerabilities (kev and vkev), so a scan can target exactly the flaws attackers are using.
Templates are code you run against production. Pin template versions, review custom and community templates, and keep the default exclusions of denial-of-service, brute force and fuzzing templates unless a test plan says otherwise.
Treat the scanner as a privileged identity. It holds target lists, sometimes credentials and API keys, and its output is a map of your weaknesses. Run it from a controlled host with least privilege and protected results.
Authorisation comes first. Scan only assets you own or have written permission to test, and tell the SOC and service owners, because Nuclei traffic looks like the reconnaissance it imitates.

What the tool does

Nuclei is a command-line engine that sends requests described in YAML templates and reports a finding when the response matches the template's conditions. The project describes it as a fast, template-based scanner and highlights low false positives by simulating real-world verification steps. It is released under the MIT licence, as is the community nuclei-templates repository. The README warns that the project is in active development with breaking changes between releases, and that running Nuclei as a service may pose security risks.

How a template is built

id: a unique identifier with no spaces, used in output and for selection with -id.
info block: name, author, severity (info, low, medium, high, critical or unknown), description, references and tags such as cve or kev. Metadata can carry search-engine queries, for example a shodan-query field.
Protocol section: the requests to send. Supported types include HTTP, DNS, TCP (network), SSL, WHOIS, WebSocket, headless browser, file, JavaScript and code.
Matchers and extractors: conditions on the response (status, words, regular expressions, DSL expressions) that decide whether there is a finding, and fields to extract as evidence.
Workflows: templates that chain others, for example detecting a product first and running its version-specific checks only when it is present.

The template library

The community repository holds around twelve thousand template files across roughly 870 directories at the time of checking, grouped by protocol (http, network, dns, ssl, file, code, cloud, dast, javascript, workflows). Its README reports KEV coverage of 454 templates for vulnerabilities in the CISA KEV catalogue and 1,449 for VulnCheck KEV, 1,496 unique in total. For comparison, the CISA catalogue held 1,754 entries in the version released on 21 October 2026, so template coverage is substantial but partial. These numbers change with every release; check the repository before quoting them.

Defender use cases

Use case	How Nuclei helps	Typical selection	What it does not cover
Rapid exposure check for a new KEV entry	Runs one template against every internet-facing host in minutes	`-id` for the CVE template, or `-tags kev`	Hosts not in your target list; vulnerabilities with no template yet
Validating scanner findings	Confirms whether a version-based finding is actually reachable	The specific CVE template	Authenticated, host-level checks
Confirming remediation	Re-runs the same check after patching or virtual patching to prove closure	Same template, same targets, saved results for comparison	Proof that the fix is permanent across rebuilds
Attack surface hygiene	Finds exposed admin panels, default pages, misconfigurations and leaked files	Tags such as `panel` and `exposure`	Business logic flaws
CI/CD regression testing	Fails a pipeline when a staging build reintroduces a known issue	Custom templates for your own past findings	Deep application testing; see the OWASP ZAP Guide
Purple team validation	Generates known request patterns so detection rules can be tested	Agreed templates in an exercise plan	Post-exploitation behaviour

The rapid KEV check is where Nuclei earns its place. Edge devices dominate recent KEV additions, and an exposed VPN or firewall can be exploited within days of disclosure, as the Ivanti Connect Secure exploitation showed. Combine the check with prioritisation from the CISA KEV Catalogue Guide and the EPSS Guide.

Deployment and safe use

Before the first scan

Get written authorisation: define scope (domains, IP ranges, exclusions), time windows and contacts. For third-party hosted assets, confirm the provider's testing policy.
Build the target list from inventory: feed hosts from your asset inventory or attack surface management tool with -l, and exclude fragile or out-of-scope systems with -eh.
Choose a dedicated scanning host: a hardened VM or container with a fixed egress IP that the SOC can allow-list for alert tuning, not a laptop.
Tell the SOC and service owners: share the source IP, schedule and template selection so alerts can be correlated rather than escalated as an attack.

Run-time controls

Control	Flag or setting	Default	Defender guidance
Global request rate	`-rl` (rate limit, requests per second)	150	Lower it for production and older devices; it takes precedence over concurrency settings
Parallel hosts per template	`-bs` (bulk size)	25	Reduce for small networks behind one firewall
Parallel templates	`-c` (concurrency)	25	Reduce when scanning a single application
Timeout and retries	`-timeout`, `-retries`	10 seconds, 1 retry	Raise timeout for slow links rather than increasing retries
Skip failing hosts	`-mhe` (max host errors)	30	Keeps a struggling device from being hammered
Severity and tag filtering	`-s`, `-tags`, `-etags`, `-id`	All non-excluded templates	Always select deliberately; never run the whole library against production by habit
Default exclusions	`.nuclei-ignore` in the templates directory	Excludes tags dos, local, fuzz, bruteforce, txt-service and weak-matcher files	Do not edit the file; override only through your config with a documented reason
Out-of-band testing	`-ni` or `-iserver`	Public Interactsh servers	Disable, or self-host, so callbacks from your network do not reach a public service
Template updates	`-ut`, `-utc`, `-duc`	Automatic check each run, stable channel	Disable auto-update on scheduled scans and update through a reviewed, pinned process
High-risk template types	`-code`, `-headless`, `-file`, `-dast`	Off	Enable only for reviewed templates in a test plan
Signature enforcement	`-dut` (disable unsigned templates)	Unsigned templates warn; unsigned code templates are blocked	Enable for production scans so only signed templates run

Template supply chain

Templates are code. ProjectDiscovery documents that all official templates carry a digital signature verified with a public key shipped in the binary, and that signing is optional for every protocol except code, where unsigned templates cannot run. Custom templates can be signed with -sign using a key in NUCLEI_USER_PRIVATE_KEY and verified with NUCLEI_USER_CERTIFICATE. For production use:

Pin versions: mirror a reviewed templates release internally and point scans at it with -ud, rather than pulling the latest on every run.
Review custom and new templates: run -validate, read what each request sends and test on a staging copy before production.
Sign internal templates: keep the signing key in your secrets manager and enable -dut so tampered templates are rejected.
Pin the engine in CI: security tools are high-value targets. In the Trivy supply chain attack, movable version tags for a scanner's GitHub Action were repointed to an infostealer that harvested pipeline secrets. Pin actions and images by digest or commit SHA.

Handling results and secrets

Structured output: write JSONL (-j with -o) or SARIF (-se) and send it to your vulnerability management platform or ticketing through the reporting configuration (-rc).
Protect results: findings are a list of exploitable weaknesses. Store them with the same access control as penetration test reports.
Credentials for authenticated scans: pass them through a secrets file (-sf) fed from your secrets manager, scoped to a dedicated low-privilege test account, never in command lines or shared configs.
Cloud upload: dashboard upload flags send results to ProjectDiscovery's cloud service. Decide deliberately whether that is acceptable under your data handling policy.

Detection and hardening value

Nuclei helps defenders in two directions: it finds weaknesses, and its traffic shows whether your monitoring would see an attacker doing the same.

Detection testing: a scheduled, announced scan is a known-good stimulus. If the WAF, IDS or SOC sees nothing when your own scanner probes for a KEV, it will see nothing when an attacker does. Map this to ATT&CK T1595.002 Vulnerability Scanning and T1190 Exploit Public-Facing Application. See the Purple Teaming Guide.
Virtual patch verification: after deploying a WAF or IPS rule for a vulnerability you cannot patch yet, the matching template shows whether the rule blocks the check. See the Virtual Patching Guide.
Regression gates: turn each confirmed finding into a custom template so it cannot quietly return in a later release.

Metrics

Time from KEV publication to completed exposure check across internet-facing assets.
Percentage of internet-facing assets in the Nuclei target list compared with the asset inventory.
Confirmed findings closed and re-verified by the same template, as a share of all confirmed findings.
Percentage of announced scans that produced the expected WAF, IDS or SIEM alerts.
Number of custom regression templates per critical application.

Alternatives

Tool category	Strength	Choose it when
Template-based scanner (Nuclei)	Fast, precise checks for specific known issues; easy custom checks	You need a quick answer for one vulnerability or a regression gate
Authenticated network vulnerability scanner (commercial products, or open source such as OpenVAS)	Broad coverage from installed package versions and configuration	You need complete, compliance-grade coverage of servers and endpoints
Dynamic application security testing (for example OWASP ZAP)	Crawls and tests application behaviour, including authenticated flows	You are testing your own web application in depth
Attack surface management platform	Discovers unknown internet-facing assets and tracks change	You do not trust your inventory of what is exposed; see the Attack Surface Management Guide
Breach and attack simulation	Tests detection and control effectiveness across the kill chain	The goal is control validation rather than finding vulnerabilities

Small organisations often get most value from running Nuclei with KEV and exposure tags against their external footprint, alongside a single authenticated scanner. Large organisations typically embed it in attack surface and CI pipelines, with an internal mirror of reviewed, signed templates.

Framework mapping

Framework	Reference	Relevance
NIST CSF 2.0	ID.RA-01, ID.IM-02	Vulnerabilities identified, validated and recorded; improvements from security tests
NIST SP 800-53 Rev. 5	RA-5, RA-5(2), CA-8, SI-2	Vulnerability monitoring and scanning; updating checks; penetration testing; flaw remediation
CIS Controls v8.1	Control 7	Continuous vulnerability management, including automated external scans
CISA	Known Exploited Vulnerabilities catalogue	Source list for KEV-driven checks
MITRE ATT&CK v20	T1595.002, T1190	The adversary behaviour the scan imitates and your detections should catch

Practitioner checklist

Record written authorisation and scope for every target range, with exclusions for fragile systems.
Run scans from a dedicated, hardened host with a fixed source IP shared with the SOC.
Mirror a reviewed templates release internally, disable automatic updates on scheduled scans and enable -dut.
Keep default exclusions; enable code, headless, file and DAST templates only in a documented test plan.
Set rate limits suitable for production and disable or self-host out-of-band interaction.
Feed targets from the asset inventory and track coverage against it.
Build a runbook that checks every new KEV entry with a template within one working day where a template exists.
Store results and any scan credentials with penetration-test-level access control.
Pin the Nuclei engine and any CI action by version digest or commit SHA.

Nuclei Vulnerability Scanner Guide: Fast, Safe Exposure Checks for Newly Exploited Flaws