Nuclei Templates Explained: How 13,000 Checks Find Bugs

In short: Nuclei templates are plain-YAML detection recipes - "send this request, and if the response looks like this, you have found that vulnerability." The community repository maintains roughly 13,000 of them, updated within days of new CVEs. A scanner's job is to run the right templates against the right targets, safely and with verified results; your job as a site owner is mostly to benefit from that coverage. Here is how the machinery actually works - and when a custom template beats the entire public pack.

If you have read a 2MNY scan report, you have seen output powered partly by Nuclei templates. Nuclei - open source, by ProjectDiscovery - has become the industry-standard engine for template-driven scanning, and it powers (in whole or part) a large share of the modern security-scanning ecosystem. Understanding how templates work makes scanner reports less magical - and shows you exactly where automation ends.

What a Template Actually Is

A template is a YAML file with four logical parts. Here is a real-world shape (simplified):

id: cpanel-old-version-exposure
info:
  name: Old cPanel version detected
  severity: low
  tags: panel, exposure, version
http:
  - method: GET
    path: "{{BaseURL}}/cpanel"
    matchers:
      - type: word
        words:
          - "cPanel 11."

The parts: metadata (id, name, severity, tags - what the finding is), the request (what to send), matchers (what response pattern confirms the finding), and optionally extractors (pull a version number or value out of the response to include in the report).

That is the whole idea. A template is a test, written once, that any Nuclei engine can run against any target. The genius is in the accumulation: thousands of researchers each encoding their specialty into one shared library.

What the 13,000-Template Pack Covers

The community repository organizes templates into families. The ones that matter most for typical websites:

• CVE detections: version-specific checks for known vulnerabilities in WordPress plugins, PHP libraries, Java components, network equipment. Published exploit? A template usually follows within days.
• Exposed panels and services: admin interfaces, database consoles, and management endpoints that should never be internet-facing - a huge share of real-world compromise paths.
• Default logins: services still running admin/admin. The internet's least glamorous vulnerability.
• Misconfigurations: directory listing enabled, permissive CORS, clickjacking exposure, missing headers.
• Exposed files and secrets: .git directories, backup archives, .env files, exposed configuration - each a one-request check that catches the exact exposures we most often find on real sites.
• Takeover and subdomain checks: dangling DNS records and vulnerable services that let an attacker claim parts of your attack surface.

Together they form a continuously-improving map of "everything already known to be broken." Running them against your site answers: which known problems apply to you, today?

How a Scanner Runs Templates Safely

Pointing 13,000 checks at a production site carelessly is how you get two problems: false positives that waste your time, and load that breaks your site. A responsible scanning pipeline - what we run at 2MNY - layers controls around the raw engine:

Target-appropriate selection. Not every template runs against every target. A WordPress plugin CVE check against a Laravel site is noise; the pipeline fingerprint the stack first (headers, paths, responses) and select template categories that can possibly match. This is why our deep audits start with reconnaissance, not template spraying.

Rate discipline. Requests are paced and concurrency-bounded. A template pack includes heavy checks (deep crawls, fuzzing wordlists); a managed scan unweights them for production targets. Sites stay up; results still arrive.

Verification and de-duplication. The raw output of any engine includes noise: the same exposure found via three templates, version-based matches against a patched backport, checks that matched an error page. The pipeline's verification layer - cross-referencing responses, re-testing high-severity findings with confirmatory requests, suppressing known false-positive patterns - is what turns a template output into a report you can act on.

Evidence capture. Every finding carries the request/response evidence, so you (or your developer) can reproduce it in one curl. A finding without evidence is a rumor.

Where Templates End and Humans Begin

Template-driven scanning has a hard boundary, and knowing it keeps your expectations calibrated:

Business logic is invisible to templates. A template can detect that your file upload accepts PHP files; no template can detect that your discount-code logic lets a customer stack coupons into a 99% discount. Logic flaws require a human who understands what the application is supposed to do.

Chaining requires creativity. A template finds an exposed endpoint; another finds a weak token format. The exploit that combines them into account takeover is an attack path - a scanner can hint at chains (we flag them), but proving exploitability is analyst work.

Zero-days are, by definition, unlisted. Templates encode what is known. The day-one vulnerability in a plugin released last week has no template yet - which is why patch discipline and defense-in-depth still matter more than any scanner.

This is the honest division of labor: automation (templates) covers the known universe cheaply and continuously; manual audit covers the unknown creatively and occasionally. You need both, on a schedule that matches your risk.

When a Custom Template Beats the Public Pack

The most underrated move in application security: encoding your own application's rules into templates.

Examples that justify a custom template: an internal admin path that must never be publicly reachable (check daily), a debug parameter that your framework exposes under load (?debug=1 - test on every deploy), a response header your gateway adds when a specific backend is misconfigured, or an API endpoint that must always require authentication (probe anonymously, alert on any 200).

A custom template is a five-line YAML file that turns "we should check that sometime" into an automated, scheduled, evidence-producing check. Teams that build a small library of these catch their most embarrassing regressions - the ones no public pack could ever know about - before customers do.

Try It From the Outside

You do not need to install anything to benefit from the template ecosystem. The free 2MNY scan runs template-driven checks across TLS, headers, DNS, exposed paths and CMS exposure - and the full pack brings the community's entire CVE corpus to bear during deep audits. Scan, read the evidence, fix the findings, re-scan. That loop - run by professionals, powered by open templates, verified by humans - is modern vulnerability management in one sentence.