# Nuclei
Nuclei is a fast, template-driven vulnerability scanner developed and maintained by ProjectDiscovery. It exists to solve a specific operational problem: security teams need to scan large, heterogeneous attack surfaces quickly and consistently, without writing custom tooling for every check. Before tools like Nuclei, practitioners either ran bloated commercial scanners with opaque logic or stitched together fragile shell scripts. Nuclei offers a third path, where detection logic lives in transparent, versioned YAML files that any engineer can read, modify, audit, or contribute. The result is a scanner that scales from a single-target assessment to continuous bulk scanning across tens of thousands of hosts, driven by a community template library that grows faster than any single vendor's internal research team could sustain.
---
Nuclei is an open-source, template-based vulnerability scanner written in Go. Its core value proposition is the separation of the scanning engine from the detection logic. The engine handles HTTP requests, DNS queries, TCP probes, SSL inspection, headless browser control, and network-level interactions. The detection logic lives entirely in YAML templates that describe what to send, what to look for in the response, and how to classify the finding.
Nuclei is not a network port scanner. It does not replace Nmap or Masscan for host discovery and port enumeration. It is not a web application fuzzer in the same category as tools like ffuf or Burp Suite's active scanner, though it supports fuzzing workflows. It is not a static analysis tool and does not inspect source code. Nuclei operates against live, running systems by sending real traffic and evaluating real responses.
Nuclei is also distinct from enterprise Dynamic Application Security Testing (DAST) platforms such as Veracode Dynamic Analysis or Invicti. Those tools are designed for compliance reporting workflows and often abstract the user away from the underlying request logic. Nuclei exposes that logic completely. Every check is readable, reproducible, and portable.
The template repository, maintained at github.com/projectdiscovery/nuclei-templates, contains over 8,000 templates at the time of writing. These templates cover CVE-specific detections, default credential checks, exposed admin panels, misconfigured cloud storage, DNS takeover conditions, SSL/TLS weaknesses, and application-level logic flaws. Templates are organized by severity, technology, and type, and they follow a peer-reviewed contribution model. Nuclei also supports private template directories for proprietary checks that organizations do not want to publish.
---
Nuclei's architecture separates into three layers: the input layer, the template engine, and the output layer.
Input Layer
Nuclei accepts targets in multiple formats: single URLs, lists of hosts in a text file, CIDR ranges, or output piped from other ProjectDiscovery tools like subfinder (subdomain enumeration) or httpx (HTTP probing). This makes Nuclei a natural downstream component in a reconnaissance pipeline. A common operational pattern is: run subfinder to enumerate subdomains, pipe into httpx to identify live HTTP services, then pipe into Nuclei to run template-based checks against confirmed live targets. Each stage filters and enriches the target list, reducing wasted scan time.
Template Engine
A Nuclei template is a YAML file with a defined schema. Every template includes a unique ID, metadata fields (name, author, severity, tags, CVE reference if applicable), and one or more protocol-specific request blocks.
For HTTP templates, the request block defines the method, path, headers, body, and optionally a list of payloads for fuzzing. After the request is sent, the matching block defines what constitutes a positive finding. Matchers can evaluate HTTP status codes, response headers, response body content using string matching or regular expressions, binary patterns, or DSL expressions that combine multiple conditions with boolean logic.
A concrete example: a template for detecting exposed Laravel debug mode would send a GET request to the target root and check whether the response body contains the string "Whoops! There was an error." with a 500 status code. If both conditions match, Nuclei reports the finding with the template's severity label. This entire check is six to ten lines of YAML and runs in milliseconds per target.
For more complex scenarios, Nuclei supports multi-step workflows using the flow field and JavaScript-based logic introduced in later versions. A multi-step template might first send a POST request to a login endpoint with default credentials, extract a session token from the response using a named capture group, then use that token in a second request to verify authenticated access. This approach allows Nuclei to detect vulnerabilities that only appear after authentication, a capability that most simple scanners completely miss.
Nuclei also supports headless browser templates that control a real Chromium instance. These templates can interact with JavaScript-heavy applications, click buttons, fill forms, and evaluate page state. This is slower than HTTP-only templates but enables detection of vulnerabilities that only manifest after client-side rendering.
At the network level, Nuclei can send raw TCP payloads and evaluate binary responses. This is used for detecting vulnerable service banners, exposed Redis instances accepting unauthenticated commands, or misconfigured memcached servers.
Concurrency and Rate Control
Nuclei parallelizes execution across both targets and templates. The operator controls concurrency with flags for parallel template execution and parallel target processing. Rate limiting is configurable per second or per minute, with options to limit by host to avoid overwhelming individual targets. For production scanning of third-party systems, these controls are essential for staying within responsible disclosure norms and avoiding accidental denial of service.
Output Layer
Nuclei outputs findings to the terminal in a human-readable format, and optionally to JSON, JSONL, Markdown, SARIF, or directly to ProjectDiscovery's cloud platform. JSON and JSONL outputs integrate cleanly with SIEM pipelines, ticketing systems, and custom dashboards. The SARIF format integrates with GitHub Advanced Security and similar code-scanning workflows, enabling Nuclei to run as part of CI/CD pipelines and report findings directly in pull request review interfaces.
Practical Scenario: Continuous Exposure Monitoring
A mid-sized organization runs Nuclei on a scheduled basis against its full external attack surface: all subdomains, all externally routed IP ranges, all known SaaS-integrated endpoints. The pipeline runs nightly. Subfinder and dnsx enumerate the current subdomain set. Httpx confirms which hosts are responding. Nuclei runs the full community template library plus a private directory of organization-specific checks, such as templates that detect internal tooling exposed to the internet or API endpoints returning sensitive field names.
Results feed into a Jira integration that opens tickets automatically for new findings and closes tickets when findings disappear. The security team reviews new findings each morning. Because every finding includes the template ID, the exact request sent, and the matched response content, engineers can reproduce and verify findings in under two minutes. False positive rates are low because templates go through community review before merging, and the organization's security team has tuned the private template set over time.
---
The business impact of undetected exposed vulnerabilities is direct and measurable. According to Verizon's Data Breach Investigations Report, the exploitation of vulnerabilities as an initial access vector accounts for a significant portion of confirmed breaches, particularly in external-facing systems. The critical failure mode is not that patches do not exist; it is that organizations do not know which of their exposed services are unpatched or misconfigured.
Traditional vulnerability management approaches rely on authenticated network scans run on a quarterly or monthly cycle. This cadence creates a structural blind spot. New services get deployed between scan windows. Subdomains get created and forgotten. Cloud storage buckets get misconfigured in minutes. A monthly scan cycle means an organization can have a publicly exploitable service exposed for weeks before anyone checks.
Nuclei addresses this with speed and automation. A full template scan against a list of 1,000 hosts completes in minutes, not hours. This makes continuous scanning operationally practical where periodic scanning using heavy commercial tools is not.
A concrete consequence: in 2021, multiple organizations suffered breaches through exposed ManageEngine and Confluence instances. In several cases, post-incident analysis confirmed that the vulnerable endpoints had been externally accessible for extended periods. Automated scanning with a tool like Nuclei, running the relevant CVE templates, would have flagged these exposures before attackers found them. The templates for these CVEs were publicly available in the community repository within days of disclosure.
A common misconception is that Nuclei is only useful for red teams or offensive security practitioners. In practice, its highest-value use case is defensive: continuous external exposure monitoring as part of an ongoing vulnerability management program. Security operations teams, not just pentesters, run Nuclei at scale. Another misconception is that open-source templates are lower quality than commercial signatures. The peer-review model and community contributor base, which includes active CVE researchers and incident responders, produces templates of comparable or superior accuracy for web-facing exposures compared to commercial alternatives.
---
CDA approaches Nuclei as an operational instrument within the Vulnerability Surface Detection (VSD) domain of the Planetary Defense Model. The governing methodology here is Continuous Surface Reduction (CSR), summarized operationally as: every surface you expose is a surface we eliminate.
CSR rejects the assumption that exposure is acceptable if it is monitored. CDA's position is that unknown or unverified exposure is a liability with a compounding risk profile. Nuclei provides the detection mechanism that makes CSR operationally real rather than aspirational. Without continuous, automated scanning that produces actionable, reproducible findings, CSR is a policy statement with no enforcement mechanism.
CDA's implementation of Nuclei differs from a standard deployment in several ways. First, CDA maintains a private template repository that extends the community library with client-specific checks. These include templates for proprietary internal tools that appear externally, templates that detect data classification markers in HTTP responses indicating potential data leakage, and templates tuned for the specific technology stacks of each client environment. This client-specific layer is version-controlled and reviewed on the same cadence as infrastructure changes.
Second, CDA integrates Nuclei output directly into the client's asset inventory and risk scoring model. A finding does not simply generate a ticket; it updates the asset's exposure score, triggers a reassessment of the associated business process risk, and feeds into the client's security posture dashboard with a remediation SLA based on severity and asset criticality. This closes the gap between detection and accountability.
Third, CDA uses Nuclei in pre-deployment validation. Before any new external service or API endpoint goes live, the relevant Nuclei templates for that technology stack and configuration type run against the staging environment. This catches misconfigurations before they reach production rather than after.
The SPH (Security Program Hygiene) dimension of Nuclei's domain classification reflects its role in demonstrating continuous due diligence. When clients face regulatory inquiries or post-incident reviews, the documented history of scheduled Nuclei scans, with timestamps, target scope, and findings, provides evidence that the organization maintained an active and technically substantive vulnerability management program.
---
---
---