Skip to main content
XML-RPC is a remote procedure call protocol that encodes its calls in XML and sends them over HTTP. WordPress exposes an XML-RPC endpoint at xmlrpc.php to support features such as remote publishing, the WordPress mobile app, and Jetpack integrations.From a security perspective, xmlrpc.php is an attractive target because:
  • It accepts wp.getUsersBlogs and similar method calls that validate a username and password on every request.
  • It is enabled by default on most WordPress installations and is often forgotten by administrators.
  • It does not enforce the same brute-force lockout policies that protect the standard wp-login.php endpoint in many configurations.
  • A single HTTP POST can attempt one credential pair, making it straightforward to automate at scale.
In a lab or CTF context, the XML-RPC endpoint is commonly configured as the intended attack surface specifically because of these properties.
No. You may only use these wordlists against systems you are explicitly authorized to test.Authorized targets include:
  • Your own local virtual machines or containers
  • CTF challenge machines on platforms such as Hack The Box or TryHackMe
  • Lab environments set up by an instructor who has granted written permission
  • Systems named in a signed penetration testing scope-of-work document
Running a brute-force attack against any website without authorization — even a small personal blog — is illegal under computer misuse and unauthorized access laws in most countries. See the Legal Notice for details.
Both tools can perform credential brute-force attacks against WordPress XML-RPC, but they differ in design and behavior:
AspectWPScanHydra
PurposeWordPress-specific scannerGeneric network login brute-forcer
XML-RPC supportNative --password-attack xmlrpc modeRequires a custom POST form template
WordPress awarenessEnumerates users, plugins, themes automaticallyNo WordPress-specific logic
OutputStructured report with vulnerability contextRaw credential hits
Typical useFull WordPress audit in a labTargeted credential testing on any HTTP form
WPScan is the preferred tool for WordPress lab exercises because it understands the application and handles the XML-RPC protocol details for you. Use it with --password-attack xmlrpc to keep requests well-formed.Hydra is useful when you need fine-grained control over the HTTP POST body, want to reuse the same toolchain across non-WordPress targets, or need to test a customized XML-RPC method name.
Start with WPScan. Switch to Hydra if you need to modify the raw XML payload or if WPScan is unavailable in your lab environment.
Send a system.listMethods request with curl. A properly enabled endpoint returns an XML response listing all available methods.
curl -s -X POST http://TARGET/lab/xmlrpc.php \
  -H "Content-Type: text/xml" \
  -d '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName><params></params></methodCall>'
Enabled and listing methods — the response body starts with:
<?xml version="1.0" encoding="UTF-8"?>
<methodResponse>
  <params>
    <param><value><array>...
Enabled but GET not accepted — a plain GET request to xmlrpc.php returns:
XML-RPC server accepts POST requests only.
This message still means XML-RPC is enabled — it just requires a POST. Use the curl -X POST command above to confirm the endpoint responds to valid requests.Disabled or blocked — you receive a 403, 404, or a redirect away from xmlrpc.php. Double-check the WordPress installation subdirectory (e.g., /lab/, /wordpress/, or the root /).
Replace TARGET with the IP address or hostname of your lab machine and adjust the path to match your installation.
users.txt covers two distinct categories of WordPress usernames commonly found in lab and CTF scenarios:Real-name usernames — Common first names and role-based names (e.g., admin, john, alice, developer, sysadmin, webmaster). These reflect realistic corporate or personal WordPress deployments where site owners use recognizable identifiers.Numbered usernames — Patterns such as user1, user2, test01, student10. These are typical of CTF challenge machines and educational lab setups where an instructor created accounts programmatically or used a simple naming scheme.Including both categories increases coverage across the two most common target types you will encounter: realistic simulated environments and purpose-built challenge boxes.
Both users.txt and passwords.txt are plain text files with one entry per line. Open either file in any text editor and append your entries.
# Add a single username
echo "ctfplayer" >> users.txt

# Add multiple passwords at once
cat >> passwords.txt << 'EOF'
LabPass2024
Summer@Lab1
P@ssw0rd!
EOF
After editing, verify there are no blank lines at the end of the file that could cause tools to send empty credential attempts:
wc -l users.txt passwords.txt
If you discover the target has a custom username during enumeration (e.g., from an author page or a WPScan user scan), prepend it to the top of users.txt so it is tried first and you save time on subsequent runs.
Too slowIncrease the thread count. Both WPScan and Hydra default to conservative concurrency. Start lower if the lab VM is underpowered, then increase until you hit the VM’s limit:
# WPScan — increase threads
wpscan --url http://TARGET/lab/ \
  --passwords passwords.txt \
  --usernames users.txt \
  --password-attack xmlrpc \
  --max-threads 100

# Hydra — increase tasks (-t)
hydra -L users.txt -P passwords.txt TARGET http-post-form \
  "/lab/xmlrpc.php:...PAYLOAD...:Incorrect username or password" \
  -t 100
Too many false positives (Hydra)Hydra identifies a “hit” by the absence of the failure string. If your failure string does not exactly match the XML-RPC error message on your target, every request looks like a success.
  1. Run a single known-bad attempt manually and capture the response:
curl -s -X POST http://TARGET/lab/xmlrpc.php \
  -H "Content-Type: text/xml" \
  -d '<?xml version="1.0"?><methodCall><methodName>wp.getUsersBlogs</methodName><params><param><value><string>wronguser</string></value></param><param><value><string>wrongpass</string></value></param></params></methodCall>'
  1. Copy the exact error text from the response (e.g., Incorrect username or password.) and paste it as the failure string in your Hydra command.
Never raise thread counts beyond what your lab environment can handle. Flooding the VM with requests may crash it and require a reset, which wastes your testing time.
Finding valid credentials is the end of the brute-force phase, not the end of the exercise. Follow these steps to complete the lab properly:
1

Document the finding

Record the exact username and password you found, the time of discovery, the command you used, and the number of attempts it took. This information belongs in your lab report.
2

Verify access

Use the credentials to log in to the WordPress admin panel (/wp-admin/) and confirm the level of access granted. Note the user role (subscriber, editor, administrator) as it determines what you can do next in the exercise.
3

Complete the lab objective

Follow the CTF challenge or lab instructions to capture the flag or demonstrate impact (e.g., post a page, access a protected area, retrieve a file). Do not perform actions beyond the defined scope.
4

Write your report

Summarize the attack path: target identification, XML-RPC enumeration, brute-force approach, credentials found, and impact. Good lab reports form the basis of professional penetration testing deliverables.
5

Reset and clean up

Remove any accounts, posts, or files you created during the exercise. If the lab provides a reset function, use it. Leave the environment in the same state you found it so the next user starts fresh.
In a real engagement, you would stop immediately after confirming access and report the finding to the client. Never use discovered credentials to explore beyond the agreed scope, even in a professional context.

Build docs developers (and LLMs) love

Get started for freeTalk to us