If you have ever looked at your server logs and seen a flood of POST requests to xmlrpc.php, you have met one of WordPress’s oldest features doing exactly what attackers love it for. It is rarely doing anything useful on a modern site, and closing it is one of the highest-value, lowest-risk hardening steps you can take.
What xmlrpc.php actually does
XML-RPC is a remote procedure call protocol that predates the WordPress REST API by many years. WordPress shipped xmlrpc.php so that external tools could talk to a site over HTTP using XML-formatted requests, things like the old WordPress mobile apps, some desktop blogging clients, and pingback/trackback notifications between blogs.
Since WordPress introduced the REST API, most modern integrations (including the current WordPress mobile apps) use that instead. XML-RPC still ships active by default in core for backward compatibility, which means every WordPress install has this endpoint sitting open unless someone closes it.
Why attackers love it
Two features of XML-RPC make it unusually attractive to attackers:
- Brute-force amplification via system.multicall. Normal login brute-forcing hits
wp-login.phpone username/password pair per request, which is slow and easy to rate-limit. XML-RPC’ssystem.multicallmethod lets a single request bundle hundreds of login attempts together. One HTTP request, hundreds of password guesses. This is far more efficient for the attacker and far harder to catch with simple rate limits that count requests rather than attempts. - Pingback abuse for DDoS and recon. The
pingback.pingmethod lets a site notify another site that it linked to it. Attackers can abuse this to make your site send a flood of requests to a third-party target, effectively turning your server into part of a distributed denial-of-service tool, or use it to probe internal network addresses and confirm whether a URL is reachable.
Neither of these requires the attacker to have any special access. The endpoint is public by design, and that is the whole problem.
Do you still need it?
Before disabling anything, figure out if something on your site genuinely relies on XML-RPC. The most common legitimate users are:
- Jetpack, which historically used XML-RPC for its connection to WordPress.com (check your Jetpack version’s current connection method if you rely on it heavily).
- Some older third-party publishing or cross-posting tools.
- Certain legacy mobile or desktop blog editors.
Check your active plugins with wp-cli before making changes:
wp plugin list --status=activeIf nothing in that list depends on remote publishing or a service you know integrates via XML-RPC, you are almost certainly safe to close it completely. If you are unsure, the safer middle path below (disabling only pingbacks) removes most of the risk while leaving the door open a crack for tools that need basic XML-RPC calls.
Option 1: Disable pingbacks only, keep XML-RPC alive
If something on your site genuinely needs XML-RPC for authenticated calls but you want to kill the DDoS-amplification vector, remove just the pingback methods with a small snippet in a must-use plugin (a file placed in wp-content/mu-plugins/):
add_filter('xmlrpc_methods', function($methods) {
unset($methods['pingback.ping']);
unset($methods['pingback.extensions.getPingbacks']);
return $methods;
});This closes the pingback abuse path while leaving other XML-RPC methods, including the ones a plugin like Jetpack might use, intact.
Option 2: Block xmlrpc.php entirely at the server
If nothing on your site needs XML-RPC, the cleanest fix is to block the file before WordPress even loads it. This is faster than a PHP-level filter and stops the brute-force amplification problem outright.
For Apache or LiteSpeed using .htaccess:
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>For Nginx:
location = /xmlrpc.php {
deny all;
}If you run Cloudflare in front of your site, you can also block or challenge requests to xmlrpc.php at the edge with a WAF rule, which stops the traffic before it ever reaches your origin server. That is often the most efficient layer to do it at, since it saves your server the work of even receiving the request.
Option 3: Use a plugin toggle
Several security and firewall plugins include a simple checkbox to disable XML-RPC, which is a reasonable option if you would rather not touch server config or a must-use plugin directly. Under the hood these typically do the same thing as the filter above, either stripping methods or returning a 403 for the endpoint. Whichever route you choose, avoid stacking multiple XML-RPC-blocking plugins at once, since overlapping filters can produce confusing behavior.
Verifying it is closed
After making a change, confirm it worked by requesting the endpoint directly:
curl -I https://example.com/xmlrpc.phpIf you fully blocked the file, you should see a 403 Forbidden response. If XML-RPC is still reachable, you will typically see a 405 Method Not Allowed for a GET request, since the endpoint expects POST, which confirms it is still live and worth revisiting.
Where this fits with the rest of your hardening
Closing XML-RPC is one lever among several that meaningfully reduce your attack surface: strong unique passwords with two-factor authentication, limiting login attempts, setting DISALLOW_FILE_EDIT in wp-config.php, keeping user roles least-privilege, and maintaining tested off-site backups. None of these replace the others. XML-RPC hardening closes a door that is specifically good for brute-force amplification and pingback abuse, but it does nothing for a compromised password on wp-login.php itself, which is why the other levers still matter.
If you host with a managed provider, it is worth asking whether XML-RPC is already blocked or rate-limited by default at the server or edge level. ServerBorn, for instance, filters this kind of abusive traffic at the edge before it reaches your site, which is one less thing to configure yourself, though it is still worth confirming your own setup rather than assuming.
The takeaway
XML-RPC exists for a version of the web that mostly no longer needs it. Check whether anything active on your site genuinely relies on it, and if not, block xmlrpc.php at the server or edge rather than leaving it exposed. If something does depend on it, strip out the pingback methods specifically, since that is the part attackers actually want. Either way, this is a five-minute fix that closes a door that has been sitting open by default for over a decade.