WordPress Hacking

WordPress powers over 40% of the web. Its attack surface is massive: core engine, 60,000+ public plugins, 10,000+ themes, REST API, XML-RPC, admin-ajax, custom PHP endpoints, WooCommerce storefronts, and multisite networks. A single outdated plugin can give you a shell. Master the enumeration-to-exploitation pipeline and you will pop WordPress sites systematically.

Triage Workflow

Follow this sequence for every WordPress target. Each step feeds the next.

Step 1 -- Confirm WordPress and Detect Version

Before running any scanner, confirm the target is WordPress and fingerprint the exact version. This determines which CVEs apply.

# Quick confirmation — check meta generator, login page, and common paths
curl -sI https://TARGET/ | grep -i 'x-powered-by\|x-redirect-by\|link.*wp-json'
curl -s https://TARGET/ | grep -oP 'content="WordPress \K[0-9.]+'
curl -s https://TARGET/readme.html | head -20
curl -s https://TARGET/feed/ | grep '<generator>'
curl -s https://TARGET/wp-includes/js/wp-emoji-release.min.js | head -1

Multiple version detection methods exist because admins disable some but rarely all. See references/wp-enum.md for the full fingerprinting matrix.

Record findings immediately:

node ${CLAUDE_PLUGIN_ROOT}/scripts/findings-tracker.js add \
  "https://TARGET" info-leak "wp-version" INFO \
  "WordPress X.Y.Z detected via meta generator"

node ${CLAUDE_PLUGIN_ROOT}/scripts/target-intel.js add \
  "TARGET" tech-stack "cms" "wordpress-X.Y.Z" --source "version-detection"

Step 2 -- Security Plugin Detection

Before aggressive scanning, identify security plugins that will block or log you. This dictates your OPSEC profile.

# Check for common security plugin signatures
curl -s https://TARGET/ | grep -iE 'wordfence|sucuri|ithemes-security|better-wp-security|all-in-one-wp-security|shield-security|bulletproof'
curl -sI https://TARGET/wp-login.php | grep -i 'x-sucuri\|x-waf'
curl -s https://TARGET/wp-content/plugins/ 2>/dev/null | grep -oP 'href="[^"]*"' | grep -iE 'wordfence|sucuri|ithemes|bulletproof|shield|cerber'

Log detected defenses:

node ${CLAUDE_PLUGIN_ROOT}/scripts/target-intel.js add \
  "TARGET" defense "security-plugin" "wordfence-active" --source "fingerprinting"

Step 3 -- User Enumeration

Enumerate WordPress users to build a target list for brute force and social engineering. Multiple methods exist because admins block some but not all.

# WPScan user enumeration
wpscan --url https://TARGET --enumerate u --disable-tls-checks

# Manual methods (when wpscan is blocked)
# Author archives — IDs 1-50
for i in $(seq 1 50); do curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" "https://TARGET/?author=$i"; done

# REST API
curl -s https://TARGET/wp-json/wp/v2/users | jq '.[].slug'
curl -s 'https://TARGET/?rest_route=/wp/v2/users' | jq '.[].slug'

# oEmbed
curl -s "https://TARGET/wp-json/oembed/1.0/embed?url=https://TARGET/" | jq '.author_name'

# Login error oracle
curl -s -d 'log=admin&pwd=wrong&wp-submit=Log+In' https://TARGET/wp-login.php | grep -oP 'Error.*?<'

See references/wp-enum.md for all enumeration vectors.

Step 4 -- Plugin and Theme Enumeration

Plugins are the primary attack surface. Enumerate aggressively.

# WPScan — aggressive plugin detection (tests ~100k slugs)
wpscan --url https://TARGET --enumerate ap --plugins-detection aggressive --disable-tls-checks

# WPScan — vulnerable plugins only (faster)
wpscan --url https://TARGET --enumerate vp --disable-tls-checks

# Theme enumeration
wpscan --url https://TARGET --enumerate at --disable-tls-checks

# Combined comprehensive scan with API token for vulnerability data
wpscan --url https://TARGET --enumerate ap,at,u,cb,dbe \
  --plugins-detection aggressive --api-token YOUR_TOKEN --disable-tls-checks

For passive enumeration without wpscan, analyze page source for /wp-content/plugins/ and /wp-content/themes/ references. See references/wp-enum.md.

Step 5 -- Vulnerability Mapping

Cross-reference enumerated components against vulnerability databases.

# WPScan with API token gives CVE data inline
wpscan --url https://TARGET --enumerate vp,vt --api-token YOUR_TOKEN --disable-tls-checks

# Nuclei WordPress templates
nuclei -u https://TARGET -tags wordpress,wp-plugin,wp-theme -severity critical,high
nuclei -u https://TARGET -tags wordpress -severity medium

# Search for specific plugin CVEs
searchsploit wordpress plugin-name
searchsploit wordpress theme-name

Log every vulnerability:

node ${CLAUDE_PLUGIN_ROOT}/scripts/findings-tracker.js add \
  "https://TARGET/wp-content/plugins/PLUGIN/" rce "PLUGIN-version" CRITICAL \
  "CVE-XXXX-XXXXX: PLUGIN vX.Y.Z RCE via ..."

node ${CLAUDE_PLUGIN_ROOT}/scripts/techniques-tracker.js add \
  wpscan "TARGET" "plugin-enumeration" success \
  --notes "Found X plugins, Y vulnerable"

Step 6 -- Exploitation

Exploit discovered vulnerabilities. See references/wp-exploits.md for vulnerability class patterns, references/wp-authentication.md for auth attacks, and references/wp-plugin-attacks.md for plugin-specific exploitation.

Step 7 -- Post-Exploitation

Once you have access (any level), escalate and persist. See references/wp-post-exploitation.md for backdoor techniques, database manipulation, and lateral movement.

node ${CLAUDE_PLUGIN_ROOT}/scripts/techniques-tracker.js add \
  manual "TARGET" "wp-post-exploitation" success \
  --notes "Shell uploaded via theme editor, wp-config.php extracted"

Decision Tree

Route your approach based on the target's configuration:

WordPress detected
├── REST API enabled (/wp-json/ returns routes)?
│   ├── YES → User enum via /wp-json/wp/v2/users
│   │         Plugin routes via /wp-json/ (custom endpoints)
│   │         WooCommerce API if /wp-json/wc/v3/ exists
│   └── NO  → Author archive enum (/?author=N)
│             Feed-based version detection (/feed/)
│
├── XML-RPC enabled (/xmlrpc.php)?
│   ├── YES → system.multicall brute force
│   │         pingback.ping SSRF
│   │         See references/wp-authentication.md
│   └── NO  → wp-login.php brute force (rate-limited)
│
├── Multisite (wp-signup.php exists)?
│   ├── YES → Enumerate subsites via /wp-sitemap.xml
│   │         Test wp-signup.php for open registration
│   │         Cross-site privilege escalation
│   └── NO  → Standard single-site methodology
│
├── WooCommerce detected?
│   ├── YES → Payment endpoint testing
│   │         Store API enumeration
│   │         Customer data exposure via REST
│   │         See references/wp-plugin-attacks.md
│   └── NO  → Standard plugin attack surface
│
├── Security plugin detected?
│   ├── Wordfence → Reduce request rate, rotate IPs
│   ├── Sucuri WAF → Test WAF bypass rules
│   ├── Cerber → Custom login URL discovery
│   └── None → Aggressive scanning safe
│
└── wp-cron.php accessible?
    ├── YES → Timing oracle for plugins
    │         DoS via cron trigger flooding
    └── NO  → DISABLE_WP_CRON likely set (good opsec by admin)

OPSEC Considerations

Request Rate Management