← Complete task index · Workspace

WordPress and SSRF Paths

← Stage index | HTTP mapping | Web cheatsheet | Strategy map | Study methods: Turn application weaknesses into access

WordPress: establish the deployment first

Recognition: WordPress-specific paths/assets, generator metadata, REST routes or wp-content. Prerequisite: correct scheme, host header and base path. Decisive output: core/plugin/theme identity or an authenticated capability that maps to a concrete prerequisite.

curl -skI https://HOSTNAME/
curl -sk https://HOSTNAME/robots.txt
curl -sk https://HOSTNAME/wp-json/ | head
curl -sk https://HOSTNAME/wp-content/
curl -sk https://HOSTNAME/wp-login.php -o wp-login.html

Inspect page source for /wp-content/plugins/NAME/, /wp-content/themes/NAME/, versioned assets and alternate base paths. A visible version is a candidate, not exploitability proof.

WPScan inventory
wpscan --url https://HOSTNAME/ --disable-tls-checks \
  --enumerate vp,vt,u --plugins-detection mixed \
  --output wpscan-HOSTNAME.txt

WPScan can be useful for component/user candidates, but verify every useful result manually. Vulnerability-database details may require an API token; never place a token in published notes or command history.

WordPress authentication and post-authentication mapping

Validate one legitimately acquired credential and then enumerate the role/capabilities it actually grants.

curl -sk -c wp.cookies -b wp.cookies \
  --data-urlencode 'log=USER' \
  --data-urlencode 'pwd=PASSWORD' \
  --data-urlencode 'wp-submit=Log In' \
  --data-urlencode 'redirect_to=https://HOSTNAME/wp-admin/' \
  https://HOSTNAME/wp-login.php -D wp-login.headers

curl -sk -b wp.cookies https://HOSTNAME/wp-admin/ -o wp-admin.html

A redirect alone is inconclusive. Confirm an authenticated page marker and the actual role. Useful capabilities can include media upload, plugin/theme editing/installation, post editing or administrative account management; each requires separate server-side authorization and execution conditions.

XML-RPC exposure is a feature clue, not automatically a vulnerability:

curl -sk -X POST https://HOSTNAME/xmlrpc.php \
  -H 'Content-Type: text/xml' \
  --data '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName><params></params></methodCall>'

SSRF: prove server-side fetching safely

Recognition: URL import, webhook, image/PDF fetch, feed preview, link unfurling or callback validation. Prerequisite: a parameter that the server dereferences. Decisive output: a request observed at a controlled listener or a stable response difference tied to the destination.

Listener:

python3 -m http.server LPORT --bind 0.0.0.0

Hypothetical request replay:

curl -sk 'https://HOSTNAME/fetch?url=http://LHOST:LPORT/ssrf-marker'

Interpret the path explicitly:

browser/client -> vulnerable application -> requested URL

The application, not Kali, must resolve and reach the destination. A browser-side fetch, open redirect or reflected URL does not prove SSRF.

Internal destination and parser variations
# Only after an external controlled callback proves server-side fetching
curl -sk 'https://HOSTNAME/fetch?url=http://127.0.0.1:PORT/'
curl -sk 'https://HOSTNAME/fetch?url=http://localhost:PORT/'

# Preserve encoding when the URL is nested in form data
curl -sk -X POST https://HOSTNAME/fetch \
  --data-urlencode 'url=http://127.0.0.1:PORT/'

Compare status, body marker, size and timing against a closed-port control. Internal HTTP content establishes reachability/read capability, not command execution.

Failure-guided routing

  • Callback never arrives: verify the parameter is fetched server-side, the listener address, return route, URL parser and allowed schemes.
  • External callback works but loopback fails: destination filtering, container/network namespace or application proxying may differ.
  • All internal ports look identical: the application may normalize errors; use a known-open/known-closed comparison and stable markers.
  • Redirect accepted but final destination blocked: determine whether validation happens before or after redirects without assuming a bypass.
  • WordPress scanner finds a component but the path/version is absent: manually confirm the active component and vulnerable configuration.

Sources