projectdiscovery/nuclei-templates

如果你已经在用或打算用 nuclei 扫描器，又想省去逐条手写检测逻辑，这套社区维护的模板库值得先看。它本身不是扫描器，价值取决于引擎，也取决于你如何挑选模板子集。

解决什么问题

安全测试者要检查一个应用是否存在已知漏洞时，原来往往从空白模板开始：读公告、推导请求形式、写好匹配条件，再对每个漏洞重复一遍。麻烦出在编写环节，而不是扫描本身。这个仓库把这一步变成直接取用：仓库里有大量写好的模板，nuclei 引擎可以直接执行。结果是测试者可以把引擎指向目标，拿到覆盖大量已知问题的检测结果，而不必为每条探测单独写脚本。

有什么不同

这是 projectdiscovery 的 nuclei 引擎官方模板集合，README 明确说模板是扫描器的核心。目录规模很大，并按 tag、严重级别、作者和目录组织：前十统计表列出 6,468 个 vuln、3,587 个 cve、3,265 个 discovery、1,269 个 xss、1,261 个 wordpress 模板，分布在 873 个目录、11,997 个文件中。HTTP、cloud、file、network、code、DAST 和工作流等目录的分布，对应引擎支持多种协议的设计。

一个实用的差异点是 KEV 映射。README 报告有 454 个模板对应 CISA 已知被利用漏洞目录，1,449 个对应 VulnCheck KEV，407 个两者重叠，去重后共 1,496 个 KEV 模板，可以用 tag 筛选。这提供了一种把扫描范围收窄到“据报已被在野利用”的漏洞的办法，而不必全量跑。

代价在于这是一个社区共同维护的语料库。覆盖面广，但各条目的深度和新旧程度并不均匀；大批量运行时，除了真实发现，还会带出大量 info 级别的探测结果（共 4,353 条），所以结果甄别是流程的一部分。官方文档说明了如何编写自定义模板，但所给摘录没有描述单个模板的维护方式或误报处理。

谁值得试

适合：已经在用 nuclei 的渗透测试者、漏洞赏金猎人和安全团队，希望立刻获得 CVE、暴露面和面板识别的覆盖，并且能按 tag 或严重级别过滤以控制扫描范围。如果你需要优先处理已被利用的问题，KEV 标签尤其相关。

不适合：没有 nuclei 引擎的人，这些文件单独无法运行；或者想要一套小而经过人工审查的检查集、又无力审阅数千条社区模板的团队。如果你要为内部应用写专门逻辑，模板仍要自己写，这个仓库更多是参考。

使用条件与边界

你需要同组织的 nuclei 扫描器，模板离开引擎没有作用。语料库体量很大，默认全量扫描又慢又吵，应当预期按 tag、严重级别或目录做筛选。单个 CVE 的覆盖依赖贡献者，缺少某条模板不代表该漏洞不存在。贡献通过 pull request 或 issue 模板提交，遇到行为疑问时可以先查 FAQ。

HotRepo 点评

HotRepo 记录到 2026-10-24 为 13,215 星（+17），2026-10-25 为 13,217 星（+18），项目创建于 2020 年。这只有两个有日期的观察点，据此无法判断热度能否持续。依赖它之前，先确认你关心的具体 CVE 或产品是否已有被维护的模板，而不是把目录规模等同于覆盖完整。