---
title: "Scan WordPress for Known CVEs"
canonical: https://trickest.com/library/wordpress-vulnerability-scanner
description: "Fingerprint a WordPress site's core, plugins and themes while scanning for known CVEs next to the component and version they hit."
---

# 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](/use-cases/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](/tools/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](/tools/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 illustrative records below match the report shape and do not come from a
real run. The fingerprint and CVE pass run in parallel against the same hosts:

```jsonl
{"domain": "example.com", "wordpress": "6.4.2", "plugins": ["contact-form-7 5.8.1", "wp-super-cache 1.9.4"], "themes": ["twentytwentyfour 1.0"], "users_enumerated": 3}
{"domain": "blog.example.com", "wordpress": "6.5.1", "plugins": ["yoast-seo 22.1", "akismet 5.3"], "themes": ["astra 4.6.8"], "users_enumerated": 1}
{"domain": "shop.example.com", "wordpress": "6.3.4", "plugins": ["woocommerce 8.9.2", "contact-form-7 5.8"], "themes": ["storefront 4.5.3"], "users_enumerated": 5}
{"domain": "news.example.org", "wordpress": "6.6.0", "plugins": ["wordfence 7.11.5"], "themes": ["twentytwentyfour 1.1"], "users_enumerated": 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](/library/directory-and-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](/library/xss-scanner). 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](/library/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.

---
_Markdown source of https://trickest.com/library/wordpress-vulnerability-scanner._