WordPress Scanner
Find common WordPress misconfigurations in seconds: exposed version, REST API user enumeration, xmlrpc.php reachability, and more. Passive — no payloads, no bruteforce.
Detects WordPress, extracts version, checks readme.html, REST API user enum, xmlrpc.php, and wp-login.php. Passive.
How to Use the WordPress Scanner
- Paste the URL of a WordPress site (the homepage is fine, e.g., https://example.com).
- Click "Scan WordPress". The tool detects if the site runs WordPress first — if not, it stops immediately.
- For WordPress sites, the scanner extracts the version from the generator meta tag and probes /readme.html, /wp-json/wp/v2/users, /xmlrpc.php, and /wp-login.php in parallel.
- Findings appear grouped by severity. Each finding has the exploitable detail + a link to the raw endpoint for you to verify.
- Use the detected version to cross-reference against wpscan.com or the WordPress changelog for specific CVEs.
What This Scanner Checks
WordPress powers 43% of the internet, which is why it's also the most targeted CMS. This scanner checks the 5 most commonly-missed security hardening steps: (1) Version disclosure — the default <meta name="generator" content="WordPress X.Y.Z"> tag tells every automated scanner the exact CVE set to target. Good themes strip it; it's the single easiest hardening win. (2) /readme.html — ships with every WordPress install and discloses the version even when the generator meta is removed. Delete it or block via .htaccess. Most hosts leave it. (3) REST API user enumeration — /wp-json/wp/v2/users returns every author's slug without auth by default. Attackers feed those slugs directly into wp-login.php brute force. Block the endpoint via a plugin (Disable REST API) or filter the users route in functions.php. (4) xmlrpc.php — the legacy remote API. Rarely needed today (Jetpack is one of the few remaining clients) but commonly enabled and enables credential brute force at 100 accounts per request, and pingback-based DDoS reflection. Disable via .htaccess. (5) wp-login.php reachability — not a vulnerability per se, but the single biggest attack surface on any WordPress site. Hide it (WPS Hide Login), add 2FA (Two Factor), and rate-limit (WordFence, Limit Login Attempts). The scanner is strictly passive — it sends at most 5 GET requests to well-known paths. No exploitation attempts, no brute force, no plugin/theme enumeration that would hammer the site. Results appear in under 10 seconds.
Frequently Asked Questions
Plugin/theme enumeration requires hundreds of HTTP requests to known paths (/wp-content/plugins/*), which (a) creates noise in the victim's access logs, (b) triggers WAF/rate limits quickly, and (c) exceeds our serverless budget. For full plugin enumeration, use WPScan (wpscan.com) or our Python CLI (PwnDeck-CLI).
Hidden version is a good minor hardening step but not real security — version can still leak via /readme.html, feed URLs (/feed/), the wp-includes/version.php file (if directory listing is on), and thousands of other subtle channels. Treat version hiding as speed-bump defense and focus on actual hardening: update core, plugins, themes, and use strong admin credentials + 2FA.
Add this to functions.php: add_filter('rest_endpoints', function ($e) { if (isset($e['/wp/v2/users'])) unset($e['/wp/v2/users']); if (isset($e['/wp/v2/users/(?P<id>[\d]+)'])) unset($e['/wp/v2/users/(?P<id>[\d]+)']); return $e; }); Or install the 'Disable REST API' plugin and restrict the /users endpoint to authenticated requests.
Your hardening may not cover readme.html specifically. Many managed WordPress hosts (Kinsta, WP Engine) strip readme.html by default. Check via: curl -I https://yoursite.com/readme.html — if you get a 200, delete the file from your webroot or add a RewriteRule in .htaccess.