Live hosts are probed and WordPress is fingerprinted. Known plugin CVEs are checked in three groups (WooCommerce, forms, other plugins) by reading each plugin's public version. Nuclei adds template coverage. Detection only. No exploit is sent.
Results
A PDF and report.json: WordPress version, plugins, exposed users, and which CVEs still match the installed versions.
Target
The site to scan. A domain, a URL, or a list. Default: example.com.
Overview
WordPress runs a large share of the web, and almost none of its exposure is in
core. It is in the plugin installed for one campaign and never updated, the theme
inherited from an agency that has since closed, the version that stopped
receiving fixes two years ago. The site works, so nobody looks.
This tells you what is actually installed and what is vulnerable about it. You
get the core version, the active plugins and themes, the exposures that are on by
default, and the CVE templates that fired, with detection and enumeration only.
Nothing here exploits. That makes it safe to schedule across a portfolio of
marketing sites, which is where this problem usually lives, and it ladders
directly into exposure management.
A template scan on its own returns identifiers. The difference here is that a
fingerprint pass runs against the same confirmed-live hosts and lands in the same
report, so a CVE arrives next to the plugin, theme and version it applies to.
That is the gap between a list of scary names and a list of things to upgrade,
and it is also what makes the report readable by whoever actually owns the site.
Both passes are distributed, so a portfolio is one run rather than one run per
host.
Two passes run in parallel against the confirmed hosts. A fingerprint pass
identifies WordPress, its core version, and the active plugins and themes,
and checks the exposures that ship enabled.
At the same time nuclei runs its WordPress CVE template set
against those hosts, distributed across the fleet.
Both land in one PDF report.
Inputs
Target(s). The site or sites to scan, as a domain, a URL, or a list. The
safe default is example.com, which completes without touching anything of
yours. Point it at a WordPress host, or paste a portfolio, to get a full report.
Template selection. The CVE and exposure templates the scan runs. The
default is the WordPress set, which is the one that matches the fingerprint.
Narrow it on the node when you only care about a single component.
Outputs
Fingerprint. The core version and the active plugins and themes with their
versions, per host.
Default exposures. The checks that ship enabled and answered: xmlrpc,
directory listing, config backups, debug logs, and the usernames readable
through the REST API.
CVE findings. Every WordPress template that matched, named alongside the
component it applies to.
PDF report. The fingerprint and the findings in one file, which reads as
an upgrade list rather than a list of identifiers.
Sample output
The fingerprint and the CVE pass run in parallel against the same
confirmed-live hosts and land in one report:
domain
wordpress
plugins
themes
users_enumerated
example.com
6.4.2
contact-form-7 5.8.1, wp-super-cache 1.9.4
twentytwentyfour 1.0
3
blog.example.com
6.5.1
yoast-seo 22.1, akismet 5.3
astra 4.6.8
1
shop.example.com
6.3.4
woocommerce 8.9.2, contact-form-7 5.8
storefront 4.5.3
5
news.example.org
6.6.0
wordfence 7.11.5
twentytwentyfour 1.1
2
Findings name the component and its version alongside the template that matched,
which is what turns the report into an upgrade list rather than a list of scary
identifiers.
FAQ
Does it exploit anything?
No. The fingerprint is low-impact GET requests and the CVE pass is detection
only. Nothing logs in, writes, or chains a finding into access, which is what
makes it safe to point at a live marketing site.
Can it scan a list of sites at once?
Yes. The target accepts a domain, a URL, or a list, and both passes are
distributed across the fleet, so a portfolio of sites completes as one run.
Why does it enumerate usernames?
WordPress exposes author accounts through its REST API by default. Knowing which
accounts exist is what separates a real credential-stuffing exposure from a
theoretical one, and that endpoint is itself one of the things worth turning off.
What does this add over running the CVE templates alone?
Template output on its own is a list of identifiers. Because the fingerprint runs
against the same hosts and lands in the same report, each match arrives next to
the plugin, theme and version that caused it, so the fix is obvious.
Is it worth running on a schedule?
Yes. Plugins get added by whoever owns the site this quarter, and they get
abandoned upstream without any change on your side. A recurring run turns the
report into a diff against the last one.
Related workflows
Directory & Content Discovery.
Reach for this instead when the site is not WordPress, or is, but the exposure
is a forgotten path rather than a plugin CVE.
Find Reflected XSS on a Domain. Reach for this instead when you want to
test the site's own parameters rather than match it against known CVE templates.
Website Screenshot and Visual Recon.
Reach for this instead when you do not yet know which hosts in scope are
WordPress and want to sort them by eye.