Use WordPress component evidence and authorized administration features

Needs: Exact component/version or a verified role; file-edit/plugin installation rights and runtime write/execution must be checked

Shell commands

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.

# Baseline
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

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

WPScan inventory

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.

# WPScan inventory
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

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

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>'

Verify → Verify application role and any produced execution identity; component names alone do not establish a vulnerable version.

If it fails → Missing editor, insufficient role or read-only filesystem changes the branch. Use exact exploit prerequisite matching or credential reuse. More detail ↓

If → then

A product/version clue, advisory or component-specific public PoC → Match a public exploit to the actual component and configuration
Needs: Exact vulnerable build/configuration, required access and endpoint behavior; reviewable source and a verifiable expected effect
A PoC, injected command or remote client reports execution → Verify command execution, host and represented identity
Needs: A functioning execution primitive and an observable output or controlled side effect
A password tied to a plausible user and service → Validate known passwords and context-specific reuse
Needs: Correct local/domain/application identity, reachable compatible service, accepted authentication and account state

No useful finding → another task in this topic. Failed check → resolve the failure before ruling out the path.

Explanation & examples

Use WordPress component evidence and authorized administration features

USE WHEN: WordPress paths/components or an accepted application administrator credential
STARTING ACCESS: A reproducible application request and a controlled input or access-context comparison
RESULT: A component-specific exploit candidate or verified administrative feature-to-execution path

Recognize the clue

Confirm WordPress-specific routes/components and inspect the capabilities actually presented after an accepted application login.

curl -sk -i http://TARGET:PORT/wp-login.php

SYNTHETIC EXAMPLE OUTPUT

Observed paths: /wp-login.php, /wp-content/plugins/COMPONENT/
Authenticated dashboard: USER_ROLE

Means: Product/component and role clues guide two different paths: exact component exploit matching or a permitted administrative feature.

Confirm: Verify build/configuration for a CVE, or actual editor/plugin/file rights plus executable handling for a feature chain.

After validation: The precise vulnerable feature or permitted file-consumer route is established: select that mechanism.
Ruled out in this context: The account lacks the relevant capability and files are read-only: discard the assumed dashboard-to-shell route.
Still inconclusive: A product path without exact version/feature evidence is insufficient for a public exploit.

Troubleshooting: Missing editor, insufficient role or read-only filesystem changes the branch. Use exact exploit prerequisite matching or credential reuse.

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.

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 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.

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

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:

Why it works

WordPress administrator, writable theme/plugin files and operating-system execution are separate facts. Multisite roles, disabled editors and filesystem ownership can remove a familiar route.

Worked example · hypothetical

Observation: a credential opens the dashboard. Test: inspect its real capabilities and whether the supported file/plugin feature is enabled. Illustrative output: the editor is disabled. Interpretation: investigate permitted components/data rather than assuming a theme shell.

New identity, privilege, host or route? Re-enumerate → All topic tasks →

Study guide ↗Full procedure ↗Cheatsheet ↗