Scanning 74,000 WordPress Vulnerabilities in One Command: Inside nuclei-wordfence-cve

Hook

Most security teams scan for hundreds of vulnerabilities. This repository scans for 74,000—and updates itself every single day without human intervention.

Context

WordPress powers 43% of the internet, making it the world's largest attack surface for web applications. Security teams face an impossible challenge: tracking vulnerabilities across 60,000+ plugins, thousands of themes, and WordPress core itself. Wordfence maintains comprehensive threat intelligence, but their data sits in an API—useful for their commercial scanner but inaccessible to teams using open-source tools like Nuclei. Meanwhile, ProjectDiscovery's official nuclei-templates repository contains excellent coverage for general web vulnerabilities but only a few hundred WordPress-specific checks.

The topscoder/nuclei-wordfence-cve repository bridges this gap with radical automation. Instead of manually curating templates, it treats Wordfence's API as a data source and programmatically generates Nuclei YAML templates for every vulnerability they track. The result is a living, breathing vulnerability database that transforms 70,000+ WordPress CVEs into scannable templates, updated daily via GitHub Actions. For security engineers managing WordPress fleets or bug bounty hunters targeting WordPress sites, this repository eliminates the manual work of tracking plugin vulnerabilities and translates threat intelligence directly into actionable scans.

Technical Insight

The architecture centers on a Python ETL pipeline that runs daily in GitHub Actions. The core script fetches two JSON feeds from Wordfence: production vulnerabilities (CVE-assigned) and candidate vulnerabilities (not yet assigned CVEs). It parses each entry, extracts metadata like affected versions, vulnerability types, and CVSS scores, then generates structured Nuclei YAML templates with proper matchers and metadata fields.

Here's how the scanning workflow looks in practice:

# Scan a target for all critical WordPress vulnerabilities
nuclei -u https://target-wordpress-site.com \
  -t nuclei-wordfence-cve/production/ \
  -severity critical

# Scan for specific plugin vulnerabilities with CVE filtering
nuclei -u https://target-wordpress-site.com \
  -t nuclei-wordfence-cve/production/plugins/ \
  -tags cve2024 \
  -severity high,critical

# Scan using a specific CVE template
nuclei -u https://target-wordpress-site.com \
  -t nuclei-wordfence-cve/production/CVE-2024-1234.yaml

The template generation logic is where this project shines. A typical auto-generated template looks like this:

id: wordfence-cve-2024-example
info:
  name: "Vulnerable Plugin Name < 1.2.3 - SQL Injection"
  author: topscoder
  severity: high
  description: "SQL Injection vulnerability in Vulnerable Plugin"
  reference:
    - https://www.wordfence.com/threat-intel/vulnerabilities/id/...
  classification:
    cvss-metrics: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
    cvss-score: 9.8
    cve-id: CVE-2024-1234
  tags: cve,wordpress,wp-plugin,sqli,high
requests:
  - method: GET
    path:
      - "{{BaseURL}}/wp-content/plugins/vulnerable-plugin/readme.txt"
    matchers-condition: and
    matchers:
      - type: regex
        part: body
        regex:
          - "Stable tag: ([0-1]\.[0-1]\.[0-9]|1\.2\.[0-2])"

The severity recalibration engine is particularly clever. Wordfence assigns severity based purely on CVSS scores, but the pipeline implements business logic to adjust ratings. For example, an authenticated SQL injection in an admin panel might get downgraded from critical to high, while an unauthenticated remote code execution in a plugin with 5 million installations stays critical. This recalibration happens in the transformation layer, using pattern matching against vulnerability descriptions and affected component metadata.

The repository organization reflects real-world scanning needs. Templates are separated into /production/ (CVE-assigned, verified vulnerabilities) and /candidates/ (reported but unverified). Within each, there are subdirectories for /plugins/, /themes/, and /core/, enabling targeted scans. A security team auditing a specific WordPress installation can scan just the plugins they've identified, rather than running all 74,000 templates.

The GitHub Actions workflow is the heartbeat of the system. Every 24 hours, it fetches fresh data from Wordfence, diffs against existing templates, generates new ones for discovered vulnerabilities, updates existing templates if severity changes, and commits everything back to the repository. This means users who clone the repo and pull daily get zero-day WordPress vulnerability coverage with near-zero latency after Wordfence publishes intel. The automation is pure infrastructure-as-code—no databases, no servers, just Git as the storage layer and GitHub Actions as the compute engine.

For integration into CI/CD pipelines, the workflow is straightforward. Clone the repo in your pipeline, use Nuclei's -t flag to point at the template directory, and parse the JSON output for vulnerability matches. Many teams schedule weekly scans against their WordPress staging environments, filtering for high/critical severities only, and automatically create Jira tickets from Nuclei's JSON output.

Gotcha

The biggest limitation is detection accuracy versus exploitation reality. These templates primarily work by fingerprinting plugin and theme versions through readme.txt files or version strings in source code. If a WordPress site has disabled readme.txt file access (a common security hardening step), hidden version information through custom code, or implemented a Web Application Firewall that blocks version enumeration requests, the templates will fail to detect vulnerabilities—even if they exist. You're not exploiting vulnerabilities; you're detecting potential exposure based on version matching.

The auto-generation process also means template quality varies significantly. A manually crafted Nuclei template by a security researcher will include multiple detection methods, edge case handling, and verified exploitation paths. These auto-generated templates are more like version checkers with CVE metadata attached. For critical infrastructure scanning, you'll want to manually review and enhance templates for your most important checks rather than trusting the automated output blindly. Additionally, the sheer volume creates noise—74,000 templates take time to run even with Nuclei's concurrency, and you'll need robust filtering strategies to avoid spending hours scanning for vulnerabilities in plugins you don't even use. The repository provides the raw materials, but you need to curate your own subset for practical scanning workflows.

Verdict

Use if: You're managing WordPress security at scale (multiple sites, WordPress-focused penetration testing, or bug bounty programs), you need comprehensive coverage of the WordPress plugin/theme ecosystem, you're comfortable with automated detection and have processes to triage results, or you're building security automation pipelines where daily-updated vulnerability intelligence provides value. This is the definitive WordPress vulnerability template collection for Nuclei users. Skip if: You're securing non-WordPress applications, you need exploitation frameworks rather than detection (check WPSploit instead), you require manually vetted templates for compliance or high-assurance environments, or you're scanning hardened WordPress installations where version fingerprinting is blocked. Also skip if you lack the infrastructure to handle 74,000 templates—this isn't a lightweight tool, and you'll need filtering discipline to extract value without drowning in scan time and false positives.