Scan WordPress for Known CVEs

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.

Pipeline

1. Read the target hosts.
2. httpx confirms which are live and answering.
3. 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.
4. At the same time nuclei runs its WordPress CVE template set against those hosts, distributed across the fleet.
5. 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.