Using Nuclei Templates Responsibly for Bug Bounty Recon
Nuclei can turn a clean host list into useful leads quickly. It can also hammer logout endpoints, trigger workflows, or submit intrusive payloads if you treat every community template as harmless. Responsible recon begins with template selection, not a giant command.
Read the bounty policy first. Check automation limits, excluded vulnerability classes, per-host rate caps, and whether cloud assets or third-party services are out of scope.
Curate before you run
Update templates, then inspect what changed. Tags and severity filters are convenient but not a safety boundary. A template marked medium may send a POST, fuzz parameters, or test a known exploit.
Start with discovery and low-impact checks:
nuclei -l live-hosts.txt -tags tech,exposure,misconfig -exclude-tags intrusive,dos,fuzz -rate-limit 5 -bulk-size 5 -concurrency 5 -jsonl -o nuclei-results.jsonl
Tune those numbers below the program's ceiling. One global rate limit can still burst a single small host when many templates target it, so split hosts or lower concurrency. Avoid -headless until you review browser templates; they may log in, click, or execute workflows.
Pin template versions for repeatable scans. Community templates evolve, and a command that was passive last month may gain an active request. Custom allowlists of template IDs are safer for recurring recon than exclusions that chase new tags.
Feed it good targets
Resolve ownership before scanning. Remove dead hosts, wildcard DNS noise, CDN error pages, and vendors excluded by the program. Normalize schemes and ports, but retain unusual web ports discovered through approved recon.
Group targets by application. Running the same 2,000 templates against every static asset domain wastes requests and hides real signals. Technology detection can route WordPress templates to WordPress hosts and Kubernetes checks to actual control-plane surfaces.
Interactsh-based templates make outbound callbacks. Use them only when out-of-band testing is allowed, and protect the correlation logs. DNS and HTTP callbacks can contain target identifiers or request data.
A match is a lead
Open the template YAML. Read the requests, matchers, extractors, and any DSL conditions. Then reproduce manually with Burp or curl. Common false positives include branded 200 error pages, version strings without vulnerable configurations, redirects to a shared login, and regexes matching JavaScript comments.
For CVE templates, establish the exact version and vulnerable behavior. “Header says Apache” is not proof of a specific CVE. For exposure templates, inspect whether returned data is private or deliberately public. Severity should reflect demonstrated impact on this target.
Write your own template only after you can reproduce the behavior manually. Use tight matchers—status plus a unique body marker and header is better than one broad word. Add stop-at-first-match when later requests add no value. Never publish a target-specific secret inside template metadata.
Keep evidence and an audit trail
Store the Nuclei version, template commit, command, timestamp, target list source, and JSONL output. Redact tokens before sharing. If the program asks why a request hit an endpoint, you should be able to name the template ID immediately.
OWASP's Web Security Testing Guide provides the manual testing context automation cannot replace. PortSwigger's Web Security Academy helps validate the underlying bug classes. Scanner-driven false positives often fall under no CWE at all; confirmed findings should map to their real weakness, such as CWE-200 for sensitive exposure or CWE-918 for SSRF. ProjectDiscovery's Nuclei running guide documents rate and concurrency controls. Slow, explainable scans produce better bounty reports than maximal coverage.