WordPress penetration testing: real attack vectors and how an installation is analysed

By Kike Gandia · Co-Founder & CEO, OSCP

A WordPress penetration test is not about running WPScan and waiting for results. It's about simulating the journey a real attacker would take: from initial enumeration to exploiting a vulnerability in a custom plugin or escalating privileges from an editor user to administrator. This guide explains what a technical WordPress penetration test covers and why it's different from any automated tool.

Phase 1: Reconnaissance and enumeration

The penetration test begins by identifying everything an attacker can discover without authentication: WordPress version, active plugins and themes (even the "hidden" ones), users enumerable via /wp-json/wp/v2/users or the author sitemap, accessible sensitive paths (/wp-config.php.bak, /wp-content/debug.log, /xmlrpc.php), and any version information in source code, headers or meta tags.

Phase 2: Plugin and extension analysis

Third-party plugins are the dominant entry vector in WordPress compromises. The analysis covers:

  • Known CVEs: Each plugin is cross-checked against the WPScan DB and NVD. Unpatched versions with public exploits are tested directly.
  • Custom code: If there are bespoke plugins or themes, the source code is reviewed for patterns of XSS, SQLi, path traversal, insecure deserialisation and dangerous PHP functions (eval, system, exec).
  • Misconfigurations: Plugins that expose REST endpoints without authentication, that allow file uploads without type validation or that store credentials in accessible WordPress options.

Phase 3: Authentication and access control testing

The /wp-admin panel is the most common target. Tests include: user enumeration through multiple methods (REST API, XML-RPC, error messages), brute-force and credential stuffing attempts against wp-login.php, authentication bypass attempts in login plugins (SSO, poorly implemented 2FA), and privilege escalation from low-privilege roles (Subscriber, Contributor) towards Editor or Administrator by exploiting plugin vulnerabilities.

Phase 4: Abusable APIs and endpoints

XML-RPC: Enabled by default, it allows remote authentication and content publishing. It's used for amplified brute-force (multiple credentials per request) and as an SSRF vector in vulnerable installations.

REST API: The /wp-json/wp/v2/ endpoints expose users, posts, taxonomies and metadata. Without proper authentication they allow mass enumeration and, in some plugins, unauthorised content writing.

What sets a WordPress penetration test apart from an automated scanner

An automated scanner finds outdated versions and public CVEs. It does not detect:

  • Vulnerabilities in custom code with no published CVE
  • Business logic flaws (role escalation, restriction bypass)
  • Vulnerabilities that require authenticated interaction
  • Active web shells disguised in legitimate files
  • Server configurations that amplify the impact of other vulnerabilities

Manual penetration testing follows an attacker's reasoning, not just a list of signatures.

FAQ

Does a WordPress penetration test require administrator access?

Not necessarily. Black-box analysis starts without credentials. If broader coverage is wanted (authenticated logic analysis, privilege escalation between roles), test accounts with different access levels are provided.

Does penetration testing affect the website's SEO or ranking?

A well-executed penetration test does not generate indexable content or modify production data. All tests are carried out in a controlled or staging environment. If work is done on production, potentially destructive tests are expressly agreed and carried out under supervision.

Related service

CMS penetration testing service

Related content

Sources

Request WordPress penetration testing