A continuously regenerated corpus of over 90,000 nuclei templates derived from Wordfence threat intelligence, built for authorized scanning of WordPress core, plugin, and theme vulnerabilities.
| Tool | topscoder/nuclei-wordfence-cve — daily-updated collection of 90,493 nuclei templates generated from Wordfence WordPress vulnerability intelligence |
| Category | Vulnerability scanning templates / template feed for nuclei |
| Primary Use | Authorized nuclei scans of WordPress assets you own or are contracted to test, filtered by -severity, -tags, -template-id, or -template-condition |
| Safe Use | Scanning your own WordPress estates or client sites under written authorization; patch verification, attack-surface inventory, and continuous vulnerability management |
| Telemetry Note | Running the full corpus generates heavy HTTP request patterns characteristic of nuclei (concurrent probes, distinctive user agent), visible in Wordfence/WAF logs and server access logs; template matching often fingerprints plugin versions via readable paths |
nuclei-wordfence-cve is a Python-driven pipeline that converts the Wordfence vulnerability intelligence feeds into a continuously maintained corpus of nuclei templates — 90,493 at the time of this writing — covering WordPress core, plugins, and themes. The README positions it squarely as a defensive asset: a way to find weaknesses in your own WordPress footprint before an attacker does. With 83,445 templates tagged wp-plugin, 6,266 tagged wp-theme, and 788 tagged wp-core, the collection mirrors the real-world risk distribution of the WordPress ecosystem, where the overwhelming majority of disclosed CVEs live in third-party plugins rather than core.
The repo sits at roughly 1,300 stars, is MIT-licensed, and carries the topic taxonomy you would expect: nuclei, nuclei-templates, projectdiscovery, bugbounty, vulnerability-management, and wordpress. What distinguishes it from a one-off dump of YAML files is the engineering around freshness: the README's dynamically generated statistics table, CI badge via test.yml, a pre-commit badge, and a last-commit badge labeled "templates added" all point to an automated generation loop that regenerates templates as Wordfence updates its feeds. For anyone running recurring authorized scans, that cadence matters more than raw volume.
Installation is idiomatic for the nuclei ecosystem. Setting GITHUB_TEMPLATE_REPO=topscoder/nuclei-wordfence-cve followed by nuclei -update-templates registers the repo as a template source, after which scans reference it via -t github/topscoder/nuclei-wordfence-cve. The README is careful to keep https://target.com as a placeholder throughout, which fits the project's framing of responsible, authorized use rather than opportunistic mass scanning.
A design decision worth understanding before you trust the output: Wordfence publishes two feeds, and the pipeline tags each generated template accordingly. The production feed contains only vulnerabilities with an assigned CVE, tagged production; the candidate feed holds pre-CVE disclosures that may or may not be promoted, tagged candidate. In practice this split is your noise dial — running with -tags production gives you a conservative, CVE-backed baseline for compliance work, while adding candidate templates surfaces freshly disclosed plugin bugs that may still lack formal identifiers but are equally real in an incident-response context.
The most interesting internal logic documented in the README is the severity recalculator, implemented as the determine_severity function in src/lib/wordfence_api_parser.py. The parser inspects vulnerability titles and descriptions and deliberately downscales issues whose impact requires an authenticated session — if the text contains authenticated without unauthenticated, the template is rated Low rather than inheriting a higher CVSS label. This is a pragmatic editorial choice: an authenticated subscriber-level XSS is a very different risk than an unauthenticated RCE on a public site, and collapsing both into High produces scan reports nobody acts on. Note that this rescaling diverges from the upstream CVSS score, which matters if your reporting obligations require the official rating — cross-check against the NVD or Wordfence entry for anything that will feed a formal risk register.
The severity distribution confirms the recalibration is aggressive: 41,818 templates are rated low against 23,706 medium, 16,139 high, and 8,830 critical, with zero info templates. For triage workflows, the -severity critical,high filter is the natural starting point for externally facing sites, and combining it with category tags (-tags wp-plugin,wp-theme -severity critical,high, as the README suggests) lets you scope scans to the asset classes you actually manage.
Granular targeting is well covered. A single-CVE lookup uses -template-id — the README's example is cve-2023-32961 — which is handy for patch verification after a specific disclosure hits the news. Category scoping uses -tags wp-core, wp-plugin, or wp-theme to align a scan with what an inventory says is actually installed. Beyond static flags, the templates inherit nuclei's -template-condition engine, and the README demonstrates expression-based selection such as contains(to_lower(name),'sql injection') or matching on XSS, file inclusion, and CSRF in names and descriptions — effectively turning the template metadata into a queryable vulnerability database.
Operationally, this corpus slots cleanly into authorized assessment workflows: pre-engagement scoping of a client's WordPress estate, continuous monitoring of your own properties inside a scheduled CI job, or bug-bounty recon on programs that explicitly permit automated scanning. It is equally useful defensively — blue teams can run it against staging mirrors of production sites to prioritize patch queues, since a confirmed template match usually implies a specific outdated plugin or theme version that remediation can target directly.
There are operational caveats a senior operator should weigh. Nearly 90,000 templates against a single host is a heavy request volume; rate limiting, concurrency caps, and scanning during off-peak windows are basic courtesy and often contractual requirements. Many plugin-version-detection templates behave like fingerprinting probes, which will light up Wordfence, WAF rules, and access-log anomaly detection — which is exactly the point if you are testing your own detection coverage, but a problem if you are not authorized to be there. The README closes with a simple "please use it responsibly," and the placeholder targets throughout make the intended scope clear.
The contribution model is conventional — fork and pull request — but the real quality signals are the automation artifacts: CI on test.yml validating generated YAML, pre-commit hooks enforcing template hygiene, and a live statistics block rendered straight into the README. Combined with the daily regeneration cadence implied by the update badges, this is a feed you can wire into nuclei -update-templates and reasonably expect to stay current without manual babysitting — which, for WordPress plugin churn, is the difference between a useful tool and a stale archive.
topscoder/nuclei-wordfence-cve.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.