Nuclei is the closest thing to a universal vulnerability scanner that bug bounty hunters and pentesters actually run at scale. This guide covers how to build automation workflows around it — from basic target sweeps to chained multi-stage pipelines that feed findings directly into your triage process.
Most hunters start with Nuclei the same way: nuclei -u https://target.com -t cves/. It works for one target. It falls apart the moment you have 400 subdomains, a rotating scope, or a program that went wide overnight.
The core problems with manual Nuclei usage are orchestration, deduplication, and triage noise. Running Nuclei in isolation — without a prior httpx probe, without scope filtering, without severity gating — produces thousands of findings that are 80% false positives and 20% things you already reported last week. The real work isn't running the scan. It's everything around it.
Scanning dead hosts wastes time and burns through template execution against 404s and connection resets.
Running all templates against every target creates massive output files with no clear prioritization path.
Nuclei results are meaningless without knowing which subdomain, endpoint, or tech stack each finding belongs to.
Re-running scans on growing target lists produces overlapping findings you have to manually diff every time.
Effective Nuclei automation isn't about running more templates faster. It's about building a pipeline where every stage produces structured output that the next stage consumes. The pattern is always: enumerate → validate → scan → triage.
When you wire Subfinder, httpx, and Nuclei together with consistent I/O formats, you get a reproducible workflow you can re-run against a target every 24 hours with zero manual setup. New subdomains get automatically swept. Severity thresholds gate what you even look at. Results are structured enough to diff against previous runs.
Always run passive enumeration before active scanning. Passive recon (Subfinder, Amass passive mode) has no footprint. Active probing (httpx, Nuclei) generates server-side logs. Sequence matters — especially on private programs where stealth is expected.
This is a production-grade pipeline that takes a root domain and produces a severity-filtered Nuclei findings report. Each stage feeds the next via output files. Run this on a VPS or schedule it as a cron job against programs you actively hunt.
Discover all known subdomains without sending a single packet to the target. Uses certificate transparency logs, DNS datasets, and search engine data.
subfinder + amass passiveFilter the subdomain list down to hosts that are actually responding. This is what you feed Nuclei — not the full enumeration output.
httpxIdentify frameworks, servers, and CMSes on live hosts so you can run targeted template categories instead of everything.
httpx -tech-detectRun Nuclei against live hosts, scoped to high-value template categories, with severity filtering to reduce noise from the start.
nucleiParse and sort findings by severity. Remove known false positives. Flag net-new findings against your last run for immediate attention.
jq + diff#!/usr/bin/env bash
# PhantomRed — Nuclei Automation Pipeline
# Usage: ./nuclei-pipeline.sh target.com
# Requires: subfinder, amass, httpx, nuclei (via go install or Homebrew)
TARGET="$1"
OUTDIR="./results/${TARGET}"
mkdir -p "$OUTDIR"
# STAGE 1 — Passive subdomain enumeration
echo "[*] Enumerating subdomains for $TARGET"
/opt/homebrew/bin/subfinder \
-d "$TARGET" \
-silent \
-o "$OUTDIR/subs-subfinder.txt"
/opt/homebrew/bin/amass enum \
-passive \
-d "$TARGET" \
-o "$OUTDIR/subs-amass.txt"
# Merge and deduplicate
cat "$OUTDIR/subs-subfinder.txt" "$OUTDIR/subs-amass.txt" \
| sort -u \
> "$OUTDIR/subs-all.txt"
echo "[*] Found $(wc -l < $OUTDIR/subs-all.txt) unique subdomains"
# STAGE 2 — Live host probing
echo "[*] Probing live hosts"
/opt/homebrew/bin/httpx \
-l "$OUTDIR/subs-all.txt" \
-silent \
-threads 50 \
-timeout 10 \
-tech-detect \
-status-code \
-o "$OUTDIR/live-hosts.txt"
echo "[*] Live hosts: $(wc -l < $OUTDIR/live-hosts.txt)"
# STAGE 3 — Nuclei scan (severity-gated, high-value templates)
echo "[*] Running Nuclei scan"
/opt/homebrew/bin/nuclei \
-l "$OUTDIR/live-hosts.txt" \
-t exposures/,cves/,vulnerabilities/,misconfiguration/ \
-severity medium,high,critical \
-rate-limit 50 \
-bulk-size 25 \
-timeout 10 \
-retries 1 \
-silent \
-json \
-o "$OUTDIR/nuclei-results.json"
# STAGE 4 — Sort and triage by severity
echo "[*] Triage summary:"
/opt/homebrew/bin/jq \
-r '[.info.severity, .host, .info.name] | @tsv' \
"$OUTDIR/nuclei-results.json" \
| sort -k1 \
> "$OUTDIR/nuclei-sorted.txt"
echo " Critical : $(grep -c 'critical' $OUTDIR/nuclei-sorted.txt)"
echo " High : $(grep -c 'high' $OUTDIR/nuclei-sorted.txt)"
echo " Medium : $(grep -c 'medium' $OUTDIR/nuclei-sorted.txt)"
echo "[✓] Results: $OUTDIR/nuclei-sorted.txt"Don't run all templates on every scan. Prioritize exposures/ for credential leaks and config files, cves/ for known CVEs, vulnerabilities/ for injection and logic flaws, and misconfiguration/ for cloud and server misconfigs. Save fuzzing templates for targeted follow-up after initial triage.
For targets with JavaScript-heavy frontends, add a katana crawl stage before Nuclei to discover endpoints that subdomain enumeration alone won't surface. See also the Recon Workflow Generator to auto-generate custom pipeline scripts for any target profile.
PhantomRed runs this entire pipeline autonomously. You submit a target domain, set your scope, and the platform handles enumeration, probing, template selection, scanning, and triage — surfacing findings in a structured dashboard rather than a flat text file.
The key difference from running scripts yourself: PhantomRed persists findings across runs, so you see net-new vulnerabilities on re-scans instead of re-triaging 400 identical results. It also applies risk scoring based on severity, exploitability signals, and asset criticality — so critical findings on authentication endpoints rank higher than medium findings on static assets.
Nuclei templates are updated automatically. New CVE templates run against your active targets within hours of release.
Findings are hashed and compared across scans. Re-scans show only what changed — not everything you already know about.
Every finding gets a risk score factoring severity, exploitability, and asset exposure. You triage in priority order, not tool output order.
No tool installation, no template management, no infrastructure. Submit a target and results appear — the pipeline runs server-side.
These are production patterns used by active bug bounty hunters. Each example is self-contained — copy, adapt for your target, and run. Explanations cover where false positives occur, why rate limiting matters, and how to handle output at scale.
The fastest way to go from a root domain to vulnerability findings. Pipes subfinder directly into httpx for live filtering, then into nuclei for scanning — no intermediate files needed for quick recon.
subfinder -d target.com -silent | httpx -silent | nuclei -t cves/,exposures/ -severity medium,high,critical -silentWithout -rate-limit, this pipeline hammers every live host simultaneously. On programs with WAFs, you'll trigger blocks that produce connection errors — which Nuclei may misreport as findings. Always add -rl 50 to the Nuclei command for any target with more than 20 live hosts.
When you already have a live.txt from a previous httpx run, skip re-probing and go straight to scanning. Gate severity at critical and high to eliminate low-signal noise before triage.
cat live.txt | nuclei -severity critical,high -rl 50 -bulk-size 25 -timeout 10 -silent -json -o nuclei-high-crit.jsonInstead of selecting by template directory, select by tag. This lets you run cross-category scans targeting specific vulnerability classes without loading unrelated templates. Useful for focused recon passes on new scope additions.
nuclei -list live.txt -tags exposure,misconfig,default-login -rl 50 -silent -json -o exposure-scan.jsonWhen you have open port data from Nmap, feed service-specific hosts directly into Nuclei with matching templates. This eliminates wasted template execution against services that aren't even running the relevant software.
# Extract hosts with port 8080 open from Nmap XML
python3 -c "
import xml.etree.ElementTree as ET, sys
tree = ET.parse('nmap-output.xml')
for host in tree.findall('.//host'):
for port in host.findall('.//port[@portid="8080"]'):
if port.find('state').get('state') == 'open':
addr = host.find('address').get('addr')
print(f'http://{addr}:8080')
" > targets-8080.txt
# Scan only those hosts with relevant templates
nuclei -l targets-8080.txt -t vulnerabilities/,panels/ -rl 30 -json -o nmap-nuclei-results.jsonNuclei JSON output contains everything — host, template ID, severity, matched URL, and extracted values. Use jq to flatten it into a triage-ready format you can diff against previous runs.
# Sort by severity, extract host + template + matched URL
jq -r '[.info.severity, .host, .info.name, .matched_at] | @tsv' nuclei-results.json | sort -k1 > triage-sorted.txt
# Count by severity
jq -r '.info.severity' nuclei-results.json | sort | uniq -c | sort -rn
# Diff against previous run (net-new only)
comm -13 <(sort previous-run.txt) <(sort triage-sorted.txt) > new-findings.txtNuclei ships with 9,000+ community templates organized into categories. Knowing which categories to run — and when — is the difference between a 10-minute targeted scan and a 3-hour noise fest. Here are the six categories that matter most for bug bounty and pentesting workflows.
Known CVEs with public proof-of-concept. Run this first on any target — one matching CVE template on a forgotten dev subdomain is often a critical finding. Update templates daily with nuclei -update-templates.
Exposed credentials, API keys, config files, and sensitive data. Detects .env files, Git repos, AWS key patterns, and database dumps. Highest signal-to-noise ratio of any category.
CORS misconfigs, open redirects, insecure headers, cloud storage misconfigs, and S3 bucket exposure. Critical for modern web apps and cloud-native targets where infra misconfig outpaces code vulns.
Admin panels, login pages, and management interfaces. Identifies exposed control planes — Jenkins, phpMyAdmin, Kibana, Grafana — that shouldn't be public. Combine with default-credentials templates.
Application-level vulnerabilities including SSRF, SQLi, XSS, path traversal, and injection flaws. More targeted than CVEs — these are class-based templates that fire on vulnerability patterns, not specific software versions.
Technology fingerprinting — CMS detection, framework identification, server software. Run this early to inform which other template categories are worth running. Knowing the target runs WordPress narrows your next scan to CMS-specific templates.
ProjectDiscovery adds CVE templates within hours of public disclosure. Running nuclei -update-templates before each scan session ensures you're testing with the latest coverage. PhantomRed does this automatically on every scan run.
Most hunters make the same five mistakes when they first automate Nuclei. Each one either burns time on false positives, misses real findings, or risks getting banned from a program. Here's what to avoid and why.
Executing nuclei -l hosts.txt with no -t flag loads 9,000+ templates. Scan time jumps from 10 minutes to 3+ hours, output is unmanageable, and you're executing fuzzing templates that generate thousands of requests per host. Fix: always scope to 3–4 template directories and gate by severity.
Running Nuclei directly against a raw subdomain list (from Subfinder or Amass) means executing templates against dead hosts, parking pages, and redirect chains. These produce misleading results — connection errors get logged as findings, and you waste execution cycles on hosts that aren't serving real content. Fix: always pipe through httpx first.
Without -rate-limit, Nuclei defaults to 150 req/sec globally. On large target lists this triggers WAF blocks, CDN bans, and program reports that you're conducting a DoS attack. Fix: set -rl 50 -bulk-size 25 as a baseline and reduce further on sensitive targets.
Re-running the same scan without comparing to previous output means you re-triage hundreds of known findings every time. On programs you actively hunt, 90% of findings on a re-scan will be identical to the last run. Fix: save JSON output per run and use comm -13 or a simple hash diff to surface only net-new findings.
Nuclei template matches require manual validation before reporting. Some templates fire on pattern matches that don't confirm exploitability — an exposed .git directory that returns a 403 is not the same as one that returns a 200 with objects. Fix: always verify the matched URL manually and confirm the finding is actually accessible and exploitable before reporting.
subfinder -d target.com -o subs.txt, then probe live hosts with httpx -l subs.txt -o live.txt, then run nuclei -l live.txt -t exposures/ -severity medium,high,critical -o results.txt. Never run Nuclei directly against raw subdomain lists — always httpx-filter first.
-rate-limit 50 to cap requests per second, -bulk-size 25 to limit concurrent hosts, and -timeout 10 for per-request cutoffs. Always start with passive recon and only escalate to active scanning after confirming program scope. For private programs, check for explicit rate-limit guidance in the program policy before running any automated scan.
Stop managing pipelines manually. PhantomRed runs the full recon-to-scan workflow autonomously and delivers risk-scored findings to your dashboard.