TL;DR
- ✓WordPress runs over 40% of all websites, so it is a massive attack surface, and the core CMS is rarely the weak point; plugins and themes are.
- ✓Most WordPress compromises trace to a known-vulnerable plugin or theme, weak admin credentials, or exposed endpoints like xmlrpc.php and the REST users API.
- ✓wpscan is the primary tool: it enumerates version, plugins, themes, and users, and checks them against the WPScan vulnerability database.
- ✓Key tests include user enumeration via the REST API and author archives, xmlrpc.php amplification and brute force, and plugin CVE matching.
- ✓Hardening basics: keep everything updated, enforce strong unique admin passwords with 2FA, disable xmlrpc and file editing, and limit login attempts.
WordPress powers more than 40% of all websites, which makes it the single largest application attack surface on the internet and a permanent favorite for opportunistic attackers. The core CMS, maintained by a large security team, is rarely the problem. The breaches almost always come from the ecosystem around it: a vulnerable plugin, an outdated theme, weak admin credentials, or an exposed endpoint left at its default.
This guide covers how to penetration test a WordPress site the way an attacker would, with wpscan as the workhorse, plus the specific endpoints worth probing (xmlrpc.php, the REST users API, author archives) and the hardening steps that close them. It fits into the broader web application pentesting checklist as a CMS-specific module.
Why is WordPress a common target?
WordPress is targeted constantly because its huge install base means a single plugin vulnerability can expose hundreds of thousands of sites at once, making automated mass exploitation extremely profitable. Attackers do not pick a site and then look for a bug; they scan the whole internet for a specific vulnerable plugin version and exploit every match.
The structural reasons are simple: there are tens of thousands of third-party plugins and themes of wildly varying code quality, site owners frequently delay updates, and default installs expose endpoints useful for enumeration and brute force. Add weak or reused admin passwords and you have the recipe behind most WordPress incidents. This makes WordPress a recurring item in any web app testing engagement that includes a CMS.
Strobes insight
WordPress core almost never gets you in. Plugins do. Treat every installed plugin as untrusted third-party code and match its exact version against the WPScan database before anything else.
How do you enumerate a WordPress site?
Enumeration means fingerprinting the WordPress version, installed plugins and themes, and valid usernames before you attack anything, and wpscan automates almost all of it. Start with a passive scan, then add aggressive plugin detection if the engagement allows.
# Core enumeration with wpscan
wpscan , url https://target.com , enumerate vp,vt,u
# vp = vulnerable plugins, vt = vulnerable themes, u = users
# Use the WPScan API token for CVE data
wpscan , url https://target.com , api-token <TOKEN> \
, enumerate ap,at,u , plugins-detection aggressive
# Manual user enumeration via the REST API
curl https://target.com/wp-json/wp/v2/users
# Author archive enumeration (redirects reveal usernames)
curl -I "https://target.com/?author=1"
The REST users endpoint and author archives both leak valid login names, which turns a password-spray into a targeted attack. Note the disclosed version against the WPScan database to find matching CVEs.
What are the most common WordPress vulnerabilities?
The bulk of WordPress findings cluster into a few categories, and plugins dominate every count. Knowing the categories tells you where to spend testing time.
- Vulnerable plugins and themes: by far the most common, ranging from SQL injection and stored XSS to unauthenticated arbitrary file upload and full RCE. Match versions to CVEs with wpscan.
- Weak credentials and brute force: /wp-login.php and xmlrpc.php both accept login attempts; xmlrpc supports multicall, letting an attacker test many passwords in one request.
- User enumeration: the REST API and author archives disclose usernames.
- xmlrpc.php abuse: pingback functionality enables SSRF and DDoS amplification, on top of credential attacks.
- Misconfiguration: exposed wp-config.php backups, directory listing, debug logs, and readable /wp-content/uploads.
WordPress Pentest Checklist
Recon
- ✓Fingerprint core version
- ✓Enumerate plugins/themes (wpscan vp,vt)
- ✓Enumerate users (REST API, author archives)
- ✓Match versions to WPScan CVE DB
Attack
- ✓Brute force wp-login.php
- ✓xmlrpc multicall amplification
- ✓pingback SSRF test
- ✓Vulnerable plugin exploitation
Config
- ✓Exposed wp-config backups
- ✓Directory listing / debug.log
- ✓Readable uploads dir
- ✓Missing security headers
How do you test xmlrpc.php and the login?
xmlrpc.php is worth dedicated testing because it enables both efficient brute force and SSRF, and it is enabled by default on many installs. First confirm it is reachable, then check whether the dangerous methods are exposed.
# Is xmlrpc enabled? A GET returns a method-not-allowed message
curl -s https://target.com/xmlrpc.php
# List available methods (look for pingback.ping and multicall)
curl -s -d '<methodCall><methodName>system.listMethods</methodName></methodCall>' \
https://target.com/xmlrpc.php
# Brute force amplification via system.multicall lets many
# wp.getUsersBlogs login attempts ride one HTTP request.
For the standard login, test for a missing lockout and rate limiting (WSTG-ATHN-03) by spraying common passwords against enumerated users with a tool like wpscan's , passwords mode or Burp Suite Intruder. pingback.ping can also be abused for blind SSRF against internal hosts, so test it the same way you would any SSRF sink.
How do you harden a WordPress site?
Harden WordPress by shrinking the attack surface and removing the default footholds, in roughly this priority order. Updates come first because vulnerable plugins are the number one cause of compromise.
- Patch aggressively: enable auto-updates for core, plugins, and themes; remove anything unused. An unused plugin is still exploitable.
- Strong auth: unique admin passwords, two-factor authentication, and a login rate-limiter or lockout plugin. Rename or restrict access to /wp-admin where feasible.
- Disable risky endpoints: turn off xmlrpc.php if unused, restrict the REST users endpoint, and disable in-dashboard file editing with
define('DISALLOW_FILE_EDIT', true); in wp-config.php. - Lock down files: correct permissions on wp-config.php, no directory listing, no exposed backups or debug logs.
- Add a WAF: a managed WAF blocks mass-exploitation of newly disclosed plugin CVEs while you patch.
For sites that change often, pairing periodic manual pentests with continuous, AI-driven coverage keeps pace with the plugin churn, which is the idea behind agentic pentesting.
Frequently asked questions
What is wpscan and how is it used?
wpscan is the standard WordPress security scanner. It fingerprints the core version, enumerates installed plugins, themes, and users, and checks them against the WPScan vulnerability database for known CVEs. With an API token it returns detailed vulnerability data, making it the first tool to run in any WordPress pentest.
Is xmlrpc.php a security risk?
It can be. xmlrpc.php enables remote publishing but also supports system.multicall, which lets attackers test many passwords in a single request for efficient brute force, and pingback.ping, which can be abused for SSRF and DDoS amplification. If your site does not need it, disabling xmlrpc.php removes that risk.
How do attackers enumerate WordPress users?
The two easiest methods are the REST API endpoint /wp-json/wp/v2/users, which can list account login names, and author archive URLs like /?author=1, which redirect to a URL containing the username. Both turn an anonymous password spray into a targeted credential attack, so they should be restricted.
Why are WordPress plugins the biggest risk?
There are tens of thousands of third-party plugins of varying code quality, and many sites delay updates. A single vulnerable plugin version can expose hundreds of thousands of sites at once, which is why attackers mass-scan for specific vulnerable versions rather than targeting individual sites. Unused plugins are still exploitable.
How do you harden a WordPress site?
Keep core, plugins, and themes auto-updated and remove unused ones; enforce strong unique admin passwords with two-factor authentication and login rate limiting; disable xmlrpc.php and in-dashboard file editing; lock down file permissions; and put a managed WAF in front to block mass exploitation of new plugin CVEs while you patch.
Can WordPress be penetration tested safely on a live site?
Yes, with care. Enumeration and version-to-CVE matching are low-risk, but brute force and active exploitation can lock out accounts or affect availability, so agree on scope and timing first. Many testers mirror the site to a staging environment for the aggressive exploitation phase to avoid impacting production.
Sources and references
A
Akhil Reni
Co-founder and CTO, Strobes
Akhil Reni is co-founder and CTO of Strobes, building AI-driven penetration testing and exposure management for security teams.
