WordPress plugin and theme checks

When an exposure scan finds that a site runs WordPress, it adds a WordPress pass: it lists the core version, plugins and themes the site gives away, looks up known vulnerabilities for the ones with an exact version, and makes a few read-only checks of common WordPress exposures.

When it runs

Profiles: Standard, Deep and Extreme, which are the profiles that inspect the website. Quick and Port-scan do not run it.
Clearance: those profiles need scan clearance, so the WordPress pass runs only on a domain the account has proven it controls.
Plans: any plan can run it by hand within the manual scan allowance. Scheduled exposure scans, which run Standard, are on paid plans only.
WordPress only: a site counts as WordPress when its homepage loads /wp-content/ or /wp-includes/ assets, carries the WordPress generator tag, or links the WordPress REST API. Any other site skips the pass and gets no extra requests.

What it reads

The inventory comes from the homepage HTML only:

Core: the WordPress version from the core asset stamps or the generator tag.
Plugins and themes: every slug under /wp-content/plugins/ and /wp-content/themes/, with its version when the asset URL carries one (?ver=). A slug seen without a version is recorded as "version not exposed". At most 100 versioned components are read.

Everything found is added to the domain's software inventory, so it also counts for KEV and CVE alerts.

Vulnerability matching

Core, plugins and themes with an exact version are looked up in the Wordfence Intelligence vulnerability feed, which DomainGuard downloads once a day and stores. Each match becomes a finding with the advisory title, the CVE when there is one, the affected version range, the CVSS score, and the version to update to. Severity comes from the advisory, or from the CVSS score when the advisory gives none.

A component without an exposed version is never matched and is never called safe. If the feed has not refreshed in the last 48 hours, or has never loaded, the scan adds an information finding, "WordPress vulnerability intelligence unavailable or stale", instead of reporting no vulnerabilities. The inventory is still recorded and is matched automatically once the feed is back.

As of September 2026 the Wordfence feed is not yet connected, so WordPress scans record the inventory and the posture checks and show that notice in place of advisory matches.

Posture checks

A handful of plain GET requests, only on WordPress sites:

Check	Finding
`/xmlrpc.php` answers	Low: XML-RPC is reachable (a common brute-force and pingback target). If it answers with an access denial, an information finding says it is blocked
`/readme.html` is public	Low: it gives away the exact core version
The REST API is linked from the homepage	Information: confirm `/wp-json/wp/v2/users` does not list usernames to anonymous visitors

The pass never guesses usernames or passwords, never tries default logins, and never probes thousands of plugin paths.

Where

Findings appear with the rest of the scan's findings, named "WordPress checks" in the app and "WordPress Intelligence" on the web, and can be dismissed like any other (Findings and dismissals). Plugins and themes show in the domain's software inventory.

Common questions

My plugin is vulnerable but no finding appeared. Either the site does not expose that plugin's version in its asset URLs, or the vulnerability feed was unavailable for that scan; the information finding says which. Check the version on the server, or add the plugin to the watchlist.

Can I hide versions from the scan? Yes, removing ?ver= stamps hides them from the scan and from anyone else, but it also means the scan cannot match them. Keeping plugins updated is the fix that matters.