Nuclei at Scale: Vulnerability Scanning and KEV Rapid Response

A part-time CISO running security for an SMB has neither a dedicated pentester nor the budget for a quarterly audit of every asset. What they need is a way to answer two questions continuously: "is my entire fleet vulnerable to what just came out" and "how far am I from active exploitation." Nuclei answers both, provided it is used as a fleet-wide vulnerability scanning engine, not as a one-off testing tool against a handful of targets.

This article covers the full method: the template model, how to scan a fleet without bringing it to its knees, rapid response to a KEV advisory, and why maintaining the template set is the real challenge, not installing the engine.

The Nuclei template model, the building block of scanning at scale

A Nuclei template is a YAML file describing a request and the condition that proves a flaw is present. Two commands are enough to understand fleet-scale usage:

# A single target, a precise tag
nuclei -u https://app.example.com -tags cve,kev
 
# An entire fleet, described in a file
nuclei -l targets.txt -tags cve,kev -severity critical,high

The targets.txt file holds one URL or host per line: this is the piece that turns Nuclei from an "I'm testing one app" tool into an "I cover my fleet" tool. The tags filter the loaded template set: cve targets signatures tied to published CVEs, kev (when the pack qualifies them that way) targets the ones matching documented active exploitation. The engine then applies each template through two mechanisms:

• Matchers decide whether the response proves the vulnerability (status code, keyword in the body, regular expression, network callback via interactsh for blind flaws).
• Extractors pull a useful piece of data from the response (a version number, a token, a path) without making any claim about vulnerability: useful for technology fingerprinting ahead of a matcher.

This matcher/extractor separation is what lets you write precise templates instead of rules that just say "the path exists."

Scanning a fleet without saturating it

The first time you run Nuclei against a fleet of several hundred assets with no tuning, two things happen: the web application firewall starts blocking the source IP, and some undersized services fall over under the load. Scanning at scale is not only a coverage question, it is a throughput question.

Before (a scan that breaks things):

nuclei -l targets.txt -t nuclei-templates/

With no rate limit and no concurrency cap, Nuclei opens as many connections as the system allows, against every target in parallel, with the full community template set loaded. On an SMB fleet with legacy applications or modest network appliances, the service goes down before the scan finishes.

After (a controlled scan):

nuclei -l targets.txt \
  -tags cve,kev \
  -severity critical,high,medium \
  -rl 150 \
  -c 25 \
  -timeout 8 \
  -retries 1

• -rl (rate limit) caps the global number of requests sent per second: this is the setting that protects fragile network equipment and applications.
• -c (concurrency) limits how many targets are processed in parallel, independently of the per-target request rate.
• -timeout prevents an unresponsive target from blocking the worker pool.
• DNS resolution needs to be checked upfront (a domain pointing to a third-party or expired IP wastes time and can scan out-of-scope infrastructure): a dedicated resolver list or a pre-validated IP list as input avoids that trap.

A scan that finishes cleanly across the whole fleet, with no collateral incident, is worth more than an aggressive scan that surfaces three vulnerabilities before taking a service down.

KEV and 0-day response: from CISA advisory to deployed template in hours

This is the second use case, and the one that truly justifies Nuclei for a CISO without a dedicated offensive team. A CISA KEV advisory drops: the flaw is confirmed as actively exploited, not just theoretical. The countdown starts, and it is measured in hours, not weeks.

The prioritization principle is straightforward to apply:

• KEV (Known Exploited Vulnerabilities): the flaw is already being exploited in the wild. This is an operational emergency, not a hypothesis to weigh.
• EPSS (Exploit Prediction Scoring System): a 30-day exploitation probability. Useful for arbitrating between two CVEs that are not yet in KEV.

Crossing "this CVE is in KEV" with "it hits an exposed asset in my fleet" produces a short, actionable list. On that list, the chain becomes: read the advisory, identify the observable behavior that proves the flaw (a path, a distinctive response, a header), write or pull the template, validate it against a known vulnerable version, then run:

nuclei -l targets.txt -tags kev -severity critical -json -o kev-results.json

The JSON output feeds directly into a remediation pipeline or a ticket. The goal is not a perfect template on the first try, it is cutting the delay between "the advisory exists" and "I know who, in my fleet, is affected."

Versioning and maintaining the template set

A template set is not a static artifact: it needs updating like any other signature base.

nuclei -update-templates

This command syncs the local template repository with the latest published version. But a raw update creates a problem in production: a template modified or removed between two scans silently changes what gets covered. Two habits limit that risk:

• Pinning: freezing a known version of the template set (by commit tag or release identifier) for reference scans, and only advancing that version after verification.
• Diffing: comparing the template set before and after an update to know what was added, changed, or removed, before running a full fleet scan against the new set.

Without this discipline, an "up to date" scan can actually cover less surface than it did a month earlier, with nobody noticing until the incident.

Reducing false positives: the discipline that changes everything

A vulnerability scan that surfaces a hundred alerts, sixty of which are noise, ends up ignored. Cutting false positives rests on three practices, not a magic setting:

• Strict matchers. A status code alone proves nothing; a version banner can be masked or left over from a partial fix. The matcher needs to target the flaw's observable behavior (a specific piece of data in the response, a combined condition via matchers-condition: and), not an indirect clue.
• Technology fingerprinting upfront. Identifying the exact technology and version before applying a targeted template avoids testing an Apache signature against an Nginx server, or a CMS version against an instance that does not even run it.
• Negative matchers. Explicitly excluding responses that resemble a known false positive (a generic error page that coincidentally contains the searched keyword) reduces noise without losing coverage.

Here too, the proof is empirical: a template that stays silent against a corpus of benign or already-patched targets, and fires only on a genuinely vulnerable one, is the only criterion that matters. "Syntactically valid" and "reliable in production" are two different things.

Why a maintained template subscription beats a stale GitHub clone

Cloning the community template repository on a given day costs one command. Maintaining it afterward costs time, every day. Two months later, without updates, that clone suffers three problems at once: new CVEs are not covered, existing templates have not picked up the false-positive fixes the community has since made, and nothing flags that a flaw now in KEV still has no matching detection in the frozen set.

A maintained template set solves that triple problem continuously: systematic prioritization by KEV and EPSS, validation of every signature against a real engine before publication, and regular updates that close the exposure window instead of letting it widen month after month.

That is exactly what the ThreatClaw Nuclei feed delivers: a maintained template set, prioritized by KEV and EPSS, ready to scan an entire fleet without saturating it, so you respond in hours rather than weeks to the next critical advisory.