wordpress vulnerability scanner

Detect whether a site runs WordPress, identify the core version, and surface known CVEs against that release. Non-invasive — only reads what the site publicly exposes.

What this tool checks

• Whether the site runs WordPress (meta generator, /wp-content/ assets, RSS feed)
• WordPress core version (multiple detection paths with fallbacks)
• Whether the detected version is below the current supported branch
• Known CVEs against the detected version (via WPScan API when configured)

Why it matters

WordPress powers ~40% of the web and is the single most-attacked CMS. Running an unsupported branch means accumulating known, weaponised CVEs — and most owners do not realise until a defacement or SEO spam campaign.

How to fix what it finds

• Update to the latest WordPress minor release (Dashboard → Updates)
• Enable automatic updates for minor and security releases in wp-config.php
• Remove /readme.html if it is publicly readable — it leaks the version number
• Patch all plugins and themes immediately; abandoned plugins should be removed
• Add a WAF (Cloudflare, Sucuri, Wordfence) to block known exploit attempts

Methodology

We fetch the public homepage and look for WordPress fingerprints in this order: <meta name="generator"> tag with a version, /wp-content/ or /wp-includes/ asset paths, readme.html (older installs), and the RSS feed's <generator> element. Once a version is found, we compare it against the current supported branch (currently 6.4+) — anything older is flagged as outdated since old branches accumulate published CVEs. When a WPSCAN_API_TOKEN is configured server-side, we additionally query the WPScan vulnerability feed and attach an authoritative CVE list with CVSS severity. The check is fully non-invasive: no auth attempts, no brute force, no requests outside what a regular visitor sees.

Frequently asked questions

Does this actually log into my WordPress site?

No. We only read what the site publicly serves to every visitor — the homepage HTML, the RSS feed, and (if available) readme.html. There is no login attempt, no enumeration of users, no scan of wp-admin.

Why does it say "not detected" on my WP site?

Some hardened installs strip the meta generator, block readme.html, and rewrite asset paths. That is a security win — it makes fingerprinting harder. If we cannot detect WordPress at all, the scanner returns a null score and skips.

Where does the CVE data come from?

When configured, we query the WPScan API — the same vulnerability feed used by Wordfence and many WP security plugins. Without an API token we fall back to a heuristic that warns on outdated branches without listing specific CVEs.

How often is the CVE feed updated?

WPScan publishes new CVEs as they are disclosed — usually within hours. Each scan hits a live endpoint, so you always get the latest data.

Should I scan competitors' WordPress sites?

Only what is publicly visible. This tool reads public HTML and headers — the same data any browser sees. It does not perform any action that could be considered an attack.

What if the scan misses a vulnerability?

Plugin and theme vulnerabilities (where ~95% of WP exploits actually live) need authenticated scanning — install a plugin like Wordfence for that depth. This tool catches the core-version risk, which is the public-facing baseline.