Skip to main content
This methodology is strictly for authorized CTF exercises and lab environments you own or have explicit permission to test. Do not apply these techniques outside of that scope.

WordPress XML-RPC attack surface

What is xmlrpc.php?

xmlrpc.php is a WordPress endpoint that implements the XML-RPC protocol — a remote procedure call standard that uses XML for encoding and HTTP as the transport. It was originally included to allow external applications (blogging clients, mobile apps, Jetpack) to interact with WordPress programmatically. The endpoint exposes a collection of methods for creating posts, managing comments, retrieving user information, and authenticating users. Because it accepts credentials directly via POST requests and returns structured responses, it is a natural target for automated brute-force attacks.

The wp.getUsersBlogs method

wp.getUsersBlogs is an XML-RPC method that returns the list of blogs associated with a WordPress user account. It requires a username and password. On success it returns blog metadata; on failure it returns a fault with the message Incorrect username or password. This predictable failure message makes the method well-suited for brute-forcing: a tool like Hydra or WPScan can test thousands of credential pairs and identify successes by the absence of the failure string in the response.

Why XML-RPC instead of wp-login.php?

Factorwp-login.phpxmlrpc.php
Rate limitingCommon; many security plugins target itLess commonly rate-limited
Multi-call supportOne attempt per requestSupports batching multiple calls
Plugin protectionHeavily monitoredOften overlooked
Automated tool supportBroadBroad (WPScan, Hydra, custom scripts)
Historically, XML-RPC received less attention from security plugins focused on the login page. While modern hardened installations protect both, many lab and legacy environments still leave xmlrpc.php exposed and unthrottled.

Phase 1: Reconnaissance

Verify that XML-RPC is enabled before running any brute-force tool.
1

Check if xmlrpc.php is accessible

Send a GET request to the endpoint:
curl http://TARGET/lab/xmlrpc.php
A correctly configured WordPress instance returns:
XML-RPC server accepts POST requests only.
A 404 response means the file does not exist or has been removed. A 403 means it is blocked by a firewall rule or plugin.
2

List available XML-RPC methods

Send a POST request using the system.listMethods call to see all methods exposed by the server:
curl -s -X POST http://TARGET/lab/xmlrpc.php \
  -d '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName><params></params></methodCall>'
If wp.getUsersBlogs appears in the response, the attack surface is confirmed.
Document your reconnaissance findings. In a CTF or lab report, this step demonstrates due diligence and confirms the attack was targeted rather than speculative.

Phase 2: User enumeration

Brute-forcing is more effective when you know which usernames are valid. Guessing both username and password from large lists is slower and noisier.
1

Enumerate WordPress users with WPScan

WPScan can enumerate usernames through the WordPress REST API or author archives:
wpscan --url http://TARGET/lab/ --enumerate u
WPScan outputs a list of discovered usernames. Record these for use in the brute-force phase.
2

Build a targeted username list

If enumeration reveals specific usernames (for example, admin or editor), create a focused username file:
echo "admin" > target-users.txt
echo "editor" >> target-users.txt
Use this smaller file instead of the full users.txt to reduce the number of attempts needed.
In many CTF scenarios the target username is admin. Start with a single-username test before running the full wordlist.

Phase 3: Brute-force attack

With a confirmed XML-RPC endpoint and a username list, choose your tool based on your goal and environment.

WPScan

WordPress-native. Handles XML-RPC automatically. Best when you want a simple, targeted attack with built-in WordPress awareness.

Hydra

Protocol-agnostic. Requires manual XML payload construction. Best when WPScan is unavailable or you need granular control over the request.
Use WPScan when:
  • You want WordPress-aware output (version info, plugin detection alongside brute-force)
  • You are working in a standard lab environment with WPScan available
Use Hydra when:
  • You need fine-grained control over the HTTP request
  • You are working in a stripped-down environment where only Hydra is available
  • You want to practice constructing XML-RPC payloads manually
See the WPScan guide and Hydra guide for exact commands and flag explanations.

Phase 4: Post-exploitation

After finding valid credentials in a lab environment, the exercise is not complete until you have documented your findings.
1

Verify the credentials

Log in to the WordPress admin panel at http://TARGET/lab/wp-admin/ using the discovered credentials to confirm they are valid.
2

Document your findings

Record the following for your lab report or CTF write-up:
  • Target URL and the XML-RPC endpoint tested
  • Tool used and exact command run
  • Time taken and number of attempts
  • Discovered username and password
  • Any observations about server behavior (rate limiting, errors, response times)
3

Note the impact

In a real-world context, valid WordPress admin credentials allow an attacker to install plugins, execute arbitrary PHP code, and take full control of the server. In your report, describe the potential impact to contextualize why this vulnerability matters.
4

Document remediation

A complete lab exercise includes identifying the fix. For XML-RPC brute-forcing, mitigations include:
  • Disabling XML-RPC entirely if it is not needed
  • Rate-limiting requests to xmlrpc.php
  • Blocking XML-RPC access by IP using .htaccess or a firewall
  • Enforcing strong, unique passwords and enabling multi-factor authentication

Responsible disclosure and CTF scope

CTF exercises operate within a defined scope. Before running any test:
  • Confirm that the target host is within the authorized scope of the exercise
  • Confirm that you are operating on your own machine or a dedicated lab network, not a shared production system
  • Never pivot from a CTF target to other systems on the same network unless the CTF rules explicitly permit it
If you discover a real vulnerability during a CTF exercise (for example, the lab environment is connected to a real system), stop immediately and report it to the organizers through the appropriate channel.

Best practices for lab exercises

Run lab targets in a virtual machine or a dedicated lab network. Avoid connecting lab VMs to your personal network or the internet unless necessary.
Start with a low thread count (-t 10 or --max-threads 10) and increase only if the server handles the load without errors. This prevents unintended denial-of-service conditions even in a lab.
Save tool output to files. Use tee with WPScan or -o with Hydra. Logs are essential for writing accurate reports and for debugging failed runs.
Before running automated tools, verify each prerequisite manually with curl. This helps you understand what the tool is doing and makes troubleshooting faster.
If you change WordPress settings during testing (for example, enabling XML-RPC), restore them to the original state when you are done so the environment is clean for the next exercise.

The tools and techniques in this guide — WPScan, Hydra, and XML-RPC brute-forcing — are legitimate security research tools used by penetration testers and security professionals worldwide. Learning how these attacks work is an essential part of understanding how to defend against them. The legal boundary is clear: testing systems without authorization is a criminal offense in most jurisdictions, regardless of intent. The educational value of these exercises depends entirely on keeping them confined to authorized lab environments.
If you are unsure whether you are authorized to test a target, assume you are not. When in doubt, ask the lab organizer or exercise coordinator before proceeding.

Build docs developers (and LLMs) love