WordPress Penetration Testing

A specialized security assessment skill for identifying vulnerabilities in WordPress installations, including core, theme, and plugin security issues using automated and manual testing techniques.

When to Use

Choose WordPress Penetration Testing when:

• Assessing the security posture of WordPress-based websites
• Testing custom themes and plugins for common web vulnerabilities
• Auditing WordPress configurations, user permissions, and file permissions
• Checking for known vulnerabilities in installed WordPress components

Consider alternatives when:

• Testing non-WordPress CMS platforms — use CMS-specific scanners
• Performing network-level penetration testing — use network security tools
• Needing continuous WordPress monitoring — use a WAF or monitoring plugin

Quick Start

Copy
# WPScan enumeration
wpscan --url https://target.com --enumerate vp,vt,u --api-token YOUR_TOKEN

# Check WordPress version and basic info
curl -s https://target.com/readme.html | grep -i "version"
curl -s https://target.com/wp-json/wp/v2/users | python3 -m json.tool

Copy
import requests
from concurrent.futures import ThreadPoolExecutor

class WPScanner:
    def __init__(self, target_url):
        self.target = target_url.rstrip('/')
        self.session = requests.Session()
        self.session.headers.update({
            'User-Agent': 'Mozilla/5.0 (Security Audit)'
        })
        self.findings = []

    def detect_version(self):
        """Detect WordPress version from meta generator tag"""
        resp = self.session.get(self.target)
        if 'generator' in resp.text:
            import re
            match = re.search(r'WordPress\s+([\d.]+)', resp.text)
            if match:
                return match.group(1)
        # Check RSS feed
        resp = self.session.get(f"{self.target}/feed/")
        match = re.search(r'generator>https://wordpress.org/\?v=([\d.]+)', resp.text)
        return match.group(1) if match else "Unknown"

    def enumerate_users(self):
        """Enumerate users via REST API and author archives"""
        users = []
        # REST API method
        resp = self.session.get(f"{self.target}/wp-json/wp/v2/users")
        if resp.status_code == 200:
            for user in resp.json():
                users.append({
                    "id": user["id"],
                    "name": user["name"],
                    "slug": user["slug"]
                })
        # Author archive enumeration
        for i in range(1, 20):
            resp = self.session.get(
                f"{self.target}/?author={i}",
                allow_redirects=False
            )
            if resp.status_code == 301:
                location = resp.headers.get("Location", "")
                if "/author/" in location:
                    username = location.split("/author/")[1].rstrip("/")
                    users.append({"id": i, "slug": username})
        return users

    def check_xmlrpc(self):
        """Test XML-RPC endpoint for brute force potential"""
        resp = self.session.post(
            f"{self.target}/xmlrpc.php",
            data='<?xml version="1.0"?><methodCall>'
                 '<methodName>system.listMethods</methodName></methodCall>'
        )
        if resp.status_code == 200 and 'methodResponse' in resp.text:
            self.findings.append({
                "type": "xmlrpc_enabled",
                "severity": "Medium",
                "detail": "XML-RPC endpoint is accessible and responds to method calls"
            })

    def check_directory_listing(self):
        """Check for directory listing on common paths"""
        paths = [
            "/wp-content/uploads/", "/wp-content/plugins/",
            "/wp-content/themes/", "/wp-includes/"
        ]
        for path in paths:
            resp = self.session.get(f"{self.target}{path}")
            if '<title>Index of' in resp.text:
                self.findings.append({
                    "type": "directory_listing",
                    "severity": "Low",
                    "path": path
                })

Core Concepts

WordPress Attack Surface

Component	Common Vulnerabilities	Testing Approach
Core	RCE, SQLi in older versions	Version detection, CVE lookup
Plugins	SQLi, XSS, file upload, LFI	WPScan, manual code review
Themes	XSS, path traversal	Template injection testing
XML-RPC	Brute force, SSRF, DoS	Method enumeration, multicall abuse
REST API	Info disclosure, auth bypass	Endpoint enumeration
wp-config.php	Database credentials, keys	Path traversal, backup file detection
File uploads	Shell upload, MIME bypass	File extension and content-type testing

Plugin Vulnerability Testing

Copy
# Enumerate installed plugins with version detection
wpscan --url https://target.com --enumerate ap --plugins-detection aggressive

# Check specific plugin for known vulnerabilities
wpscan --url https://target.com --enumerate vp --api-token $WPSCAN_TOKEN

# Test for common plugin file exposure
for plugin in $(curl -s https://target.com/wp-content/plugins/ | grep -oP 'href="\K[^"]+'); do
    echo "[*] Found plugin directory: $plugin"
done

Configuration

Option	Description	Default
target_url	WordPress site URL to test	Required
wpscan_api_token	WPScan API token for vulnerability database	""
enumerate	What to enumerate: users, plugins, themes	"vp,vt,u"
detection_mode	Plugin detection: passive, mixed, aggressive	"mixed"
brute_force	Enable login brute force testing	false
wordlist	Path to password wordlist	""
max_threads	Concurrent request threads	5
proxy	HTTP proxy for request inspection	""

Best Practices

1. Always start with passive enumeration before aggressive scanning — check the page source, RSS feeds, and REST API first to gather information without triggering security alerts or rate limiting
2. Test XML-RPC multicall amplification specifically because it allows attackers to try hundreds of passwords in a single request, bypassing most brute force protections and rate limiters
3. Check for backup files and exposed configurations by testing paths like wp-config.php.bak, wp-config.php~, .wp-config.php.swp, and common backup naming patterns that developers accidentally leave accessible
4. Enumerate all plugins including inactive ones since inactive plugins with known vulnerabilities can still be accessed directly via their PHP files if the plugin directory is accessible
5. Test file upload functionality thoroughly by attempting to upload PHP files with double extensions (.php.jpg), modified content types, and by checking if the uploads directory allows script execution

Common Issues

WPScan API rate limiting: The free WPScan API tier limits the number of vulnerability lookups per day. Register for an API token to increase limits, cache results locally for repeat scans, and prioritize checking plugins with the oldest update dates since those are most likely to have known vulnerabilities.

WAF blocking scanning attempts: WordPress security plugins like Wordfence detect and block WPScan signatures and aggressive enumeration. Slow down request rates, rotate User-Agent strings, and use manual browser-based testing for the initial reconnaissance phase before running automated tools from an allowlisted IP.

False sense of security from outdated scans: WordPress plugins update frequently and new vulnerabilities are disclosed daily. Run scans with an updated WPScan database, cross-reference findings against the WordPress vulnerability database directly, and check plugin changelogs for security-related entries since the last scan.