projectdiscovery/nuclei-templates: what the template repository contains and how to run it

The problem nuclei-templates solves, and who it is actually for

Writing detection logic for each CVE, misconfiguration and exposed panel by hand does not scale past a handful of targets. This repository is the shared answer: a community curated list of templates for the nuclei engine to find security vulnerabilities in applications, as the README puts it. Each template is a check for one thing, written in a declarative format, and the repository collects roughly 12,000 files across 873 directories according to its own statistics table.

The audience is narrower than the topic list suggests. The topics include bugbounty, exploit-development and fingerprint, and the statistics show what that mix produces: 6,468 templates tagged vuln, 3,587 tagged cve, but also 3,265 tagged discovery and 4,353 rated info. If you are a penetration tester or a bug bounty hunter running nuclei against a scope you are authorised to test, that spread is useful. If you are building a vulnerability management programme that needs a clean signal-to-noise ratio, the info and discovery templates are the ones you will spend time filtering out.

How the repository is laid out and how a template reaches a target

The top level is organised by protocol rather than by vendor or CVE: http/, dns/, network/, file/, headless/, javascript/, code/, cloud/, dast/, ssl/ and workflows/. The statistics table counts 9,281 http templates, 659 cloud, 436 file, 259 network, 251 code, 240 dast, 92 javascript, 38 ssl and 26 dns, plus 205 workflows. A workflow chains several templates so one command can run a sequence of checks.

Templates carry tags, and the repository documents one tag family explicitly. CISA KEV coverage is given as 454 templates, VulnCheck KEV as 1,449, and 407 templates covering vulnerabilities in both catalogs, for a stated total of 1,496 unique KEV templates. The README gives the invocation for that subset directly: nuclei -tags kev,vkev. Severity is also a first-class field, with 1,555 critical, 2,552 high, 2,457 medium, 330 low, 4,353 info and 54 unknown.

Two sibling files matter for anyone wiring this into automation. TEMPLATES-STATS.md holds the expanded statistics, and TEMPLATES-STATS.json exposes the same data for integration. cves.json and cves.json-checksum.txt, along with templates-checksum.txt, are what an updating client uses to decide whether its local copy is stale.

Installing nuclei-templates and running a first real check

The repository does not ship a scanner. Templates are the core of the nuclei scanner, and the scanner is a separate project at github.com/projectdiscovery/nuclei. In practice you install nuclei, and the templates arrive with it; the README points to https://docs.projectdiscovery.io/templates/introduction for building your own templates rather than for installation instructions, and the repository does not document a standalone install for the template set.

The one command the README states explicitly is the tag filter for actively exploited vulnerabilities. It is the smallest useful first run, and the README describes the tag pair as the way to scan for vulnerabilities covered by the CISA and VulnCheck catalogs:

nuclei -tags kev,vkev

Adding your own checks means adding template files. The repository root carries TEMPLATE-CREATION-GUIDE.md and TEMPLATE-REVIEW-GUIDE.md, and contributions are expected through pull requests or the template submission issue form. The README does not document flags for update, version output or a custom template path, so check the scanner's own documentation for those before scripting anything around this repository.

Where the template model breaks down

A template is a match, not a verdict. The library contains 4,353 info and 3,265 discovery templates, and those are designed to describe what a service is, not to assert that it is vulnerable. Running the full set against a production estate and feeding the output into a ticketing system produces a queue dominated by fingerprinting results. The severity filter is the mitigation, and it has to be applied deliberately.

The second limitation is version coupling. Templates are written against the syntax the nuclei engine of the time accepts, and the repository publishes frequently: v10.4.7 on 2026-08-03, v10.4.8 on 2026-08-24, v10.4.9 on 2026-09-16. A pinned, old nuclei binary against a freshly updated template directory is a mismatch the README does not address. There is no documented rollback path for a bad template update, and no documented compatibility matrix between template versions and engine versions.

Third, this is not an authenticated scanner. The directory counts show 9,281 http templates against 240 dast templates, and nothing in the repository describes session handling or credential injection. Deep application logic flaws behind a login are outside what this collection is built to find. Finally, the language label on the repository is JavaScript, which reflects the javascript/ directory of 92 templates and the tooling around the project, not the content of the library: the templates themselves are declarative files.

The real alternative: a general-purpose scanner with its own check format

The closest alternative in kind is a traditional vulnerability scanner such as OpenVAS or Nessus, and the difference is architectural rather than a matter of coverage lists. Those tools bundle the engine and the checks in one product, ship a feed, and present results through a managed console. You do not choose which checks exist; the vendor does.

nuclei-templates inverts that. The checks are a public, MIT-licensed repository you can read, fork, edit and pin, and the engine is a separate binary you can embed in a pipeline. That is a genuine advantage for teams that need to add a check for an internal service the day it ships, and a genuine disadvantage for teams that want a vendor to own detection quality. The trade is control against support: with this repository you get the raw templates and the review guides, and you own the false positive rate.

The narrower alternative is writing your own checks and skipping the shared library entirely. That is reasonable if your estate is small and unusual, but it discards the KEV coverage, which is the part of this repository that is hardest to reproduce by hand.

Upgrade cost, maintenance and licence

Maintenance here is continuous rather than periodic. The last push was on 2026-09-21, and three releases landed between 2026-08-03 and 2026-09-16. If you pin templates for reproducibility, you are choosing to miss newly published checks; if you track the default branch, you accept that the template set changes under you. Neither choice is documented as supported, and the repository provides checksum files precisely so that tooling can detect the drift.

Contributions flow through pull requests and issue forms, and the root carries CONTRIBUTING.md, CODE_OF_CONDUCT.md and a pre-commit configuration, so the review path is visible in the repository layout. Running the library also has a cost that is easy to overlook: a full sweep across a large scope is a lot of outbound requests, and the discovery and info templates are what make that number large.

The licence is MIT. That permits commercial use and modification, but it also means the templates carry no warranty, and a template that produces a false positive or a false negative is your problem to triage. This is a description of the licence, not legal advice; check the terms yourself if redistribution is part of your plan.

Editorial conclusion

Adopt nuclei-templates if you already run nuclei and need a maintained, MIT-licensed check library, especially if CISA KEV or VulnCheck KEV coverage matters to your triage. Do not adopt it as a standalone scanner: the repository contains templates and no engine, so nothing runs without the nuclei binary. Before trusting a scan, verify three things: that your nuclei version accepts the template syntax you are running, that the templates directory you edit is the one the engine reads, and whether the templates you rely on are marked info or discovery rather than vuln. The KEV tags are the most defensible starting point, but a tag match is a claim about coverage, not proof that your target is exploitable.

Frequently asked questions

Official sources

1. License: MIT
2. projectdiscovery/nuclei-templates on GitHub
3. Project website
4. README
5. Releases