70,000 WordPress Vulnerabilities in One Command: Inside the Nuclei-Wordfence Pipeline
Hook
While most security tools ship with hundreds of templates, topscoder/nuclei-wordfence-cve generates over 70,000—automatically, daily, without human intervention. It’s turned vulnerability disclosure into an assembly line.
Context
WordPress powers 43% of the web, making it the largest attack surface on the internet. The Wordfence Threat Intelligence team maintains the most comprehensive database of WordPress vulnerabilities—tracking every plugin, theme, and core CVE with granular metadata. Meanwhile, Nuclei has become the de facto standard for vulnerability scanning in bug bounty and penetration testing, thanks to its YAML-based template system that’s both human-readable and blazingly fast.
The problem? These two ecosystems existed in parallel. Wordfence data lived in JSON feeds accessible via API, while Nuclei required YAML templates written by hand. Security researchers were stuck manually translating Wordfence disclosures into Nuclei templates, creating a lag between vulnerability disclosure and scannable detection rules. The topscoder/nuclei-wordfence-cve project eliminates this gap entirely with an automated parser that bridges both worlds, transforming 71,931 Wordfence vulnerabilities into immediately usable Nuclei templates within hours of disclosure.
Technical Insight
The architecture is elegant in its simplicity: a Python parser (wordfence_api_parser.py) queries two Wordfence API endpoints—production vulnerabilities and candidate disclosures—then generates templated YAML files following Nuclei’s v2.9.0 specification. The genius is in how it maps Wordfence’s vulnerability metadata into Nuclei’s matcher syntax.
Each Wordfence vulnerability contains version ranges, affected components, and CVE identifiers. The parser transforms this into Nuclei’s HTTP request matchers. For a vulnerable plugin, it generates a request to the plugin’s readme file (the standard WordPress disclosure mechanism), then uses regex matchers to extract version numbers and compare against known vulnerable ranges. Here’s a simplified example of what the generator produces:
id: wordfence-cve-2024-12345
info:
name: "Vulnerable Plugin XYZ <= 2.3.4 - SQL Injection"
author: topscoder
severity: high
description: "The Plugin XYZ plugin for WordPress is vulnerable to SQL Injection via the 'id' parameter in versions up to 2.3.4"
reference:
- https://www.wordfence.com/threat-intel/vulnerabilities/id/abc123
classification:
cvss-metrics: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
cvss-score: 8.8
cve-id: CVE-2024-12345
tags: wpscan,wordpress,wp-plugin,high
requests:
- method: GET
path:
- "{{BaseURL}}/wp-content/plugins/plugin-xyz/readme.txt"
matchers-condition: and
matchers:
- type: regex
part: body
regex:
- "Stable tag: ([0-2]\.[0-3]\.[0-4]|[0-2]\.[0-2]\..*|[0-1]\..*)"
- type: status
status:
- 200The severity recalculation logic is particularly sophisticated. Wordfence rates vulnerabilities based on their original CVSS scores, but the parser implements additional heuristics. If a vulnerability requires authentication (PR:H in CVSS metrics) but has a critical CVSS score, the parser may downgrade it to ‘high’ for more practical triage. Conversely, unauthenticated remote code execution always maps to ‘critical’ regardless of Wordfence’s original rating. This real-world severity adjustment helps security teams prioritize actual risk over theoretical impact.
The daily automation runs via GitHub Actions, fetching fresh data from Wordfence’s production and candidate feeds. The workflow parses JSON responses, generates YAML templates with Jinja2 templating, validates them against Nuclei’s schema, then commits directly to the repository. This creates an always-current vulnerability database with zero manual intervention. The candidate feed is particularly valuable—it includes vulnerabilities awaiting CVE assignment, giving researchers a 2-4 week head start on detecting zero-days before official disclosure.
Filtering is where this tool truly shines. With 70,000+ templates, running everything is impractical. The project provides a comprehensive tagging taxonomy: wp-core, wp-plugin, wp-theme for component types; production and candidate for disclosure status; severity levels; and CVE identifiers. You can scan for only critical plugin vulnerabilities affecting e-commerce sites:
nuclei -u https://target.com \
-t nuclei-wordfence-cve/candidate/ \
-severity critical \
-tags wp-plugin,woocommerceOr audit a specific CVE across your entire WordPress estate by filtering on CVE tags. The granularity transforms a brute-force template dump into a surgical security assessment tool. The README provides filter examples for common scenarios: finding all SQL injection vectors, scanning only authenticated vulnerabilities, or checking themes from a specific vendor.
Gotcha
The fundamental limitation is that these are detection templates, not exploitation modules. They identify vulnerable versions by checking readme files and version strings, not by actually exploiting the flaw. This creates two problems: false positives on patched systems where version numbers weren’t updated, and false negatives on custom WordPress installations where readme.txt files are deleted for security hardening. If a developer removes all version disclosure mechanisms (a common security practice), these templates will miss vulnerabilities entirely.
Performance is the second major constraint. Even with filtering, you’re often running thousands of templates against a single target. Nuclei handles this reasonably well with parallel requests, but expect scan times of 15-30 minutes for comprehensive WordPress assessments. The template volume also creates local storage challenges—the repository itself is over 500MB when cloned, which can be problematic in CI/CD pipelines or containerized scanning environments. There’s no incremental update mechanism; you clone everything or nothing. For teams running automated scans across hundreds of WordPress sites, the compute and storage costs add up quickly.
Verdict
Use if: You’re managing WordPress security at scale (agency, bug bounty, enterprise security team) and need comprehensive, always-current vulnerability coverage with granular filtering capabilities. This is the fastest path from Wordfence disclosure to actionable scan results, and the tagging system lets you build highly targeted assessment workflows. Perfect for continuous monitoring pipelines where you want daily updates without manual template maintenance. Skip if: You need active exploitation capabilities rather than passive detection, are testing non-WordPress applications, require offline scanning without internet-connected template updates, or operate in environments where 500MB+ repository sizes and 20+ minute scan times are prohibitive. Also skip if you’re new to Nuclei—start with the official template collection to learn the tooling before tackling 70,000 specialized WordPress templates.
