Most WordPress site owners obsess over strong passwords, two-factor authentication, and login page lockouts. Yet, on millions of servers, an old legacy protocol sits quietly in the background, listening for requests and letting automated bots hammer away at credentials without triggering standard security alerts: xmlrpc.php.
Password attacks hitting XML-RPC occur at nearly the same rate as those targeting the standard /wp-login.php interface. If you have not deliberately closed this entry p0int, your server is likely expending resources defending itself against automated brute-force attacks around the clock.
What is XML-RPC (and Why Does WordPress Still Have It)?
XML-RPC is a Remote Procedure Call protocol that uses XML to encode data and HTTP as its transport layer. It was created to allow external tools and applications to communicate with your WordPress site remotely.
Before the modern WordPress REST API became the standard, XML-RPC was responsible for:
- Connecting the official WordPress mobile app to your site.
- Enabling remote desktop publishing software.
- Managing trackbacks and pingbacks.
- Bridging communication between your site and cloud services like Jetpack.
WordPress prioritizes backward compatibility, meaning xmlrpc.php ships enabled by default on every new installation. For the vast majority of modern websites that do not rely on legacy desktop clients, mobile publishing apps, or pingbacks, this file offers no active benefit – it just widens your attack surfacae.
The Primary Security Risks
Attackers frequently target XML-RPC due to two specific architectural weaknesses:
1. Brute-Force Amplification via system.multicall
Standard login pages can be easily protected with limit-login plugins that block an IP after a few failed tries. XML-RPC circumvents standard login forms entirely. Through the system.multicall method, an attacker can bundle hundreds or even thousands of username and password guesses into a single HTTP request. To the web server, it looks like one routine interaction, but internally WordPress processes every single login attempt. This bypasses basic IP-based rate limiters and drastically accelerates credential guessing.
2. Pingback DDoS Reflection
Attackers can abuse the XML-RPC pingback feature to turn thousands of unsuspecting WordPress sites into a distributed denial-of-service network. By sending a forged request stating that another site linked to your post, an attacker forces your server to reach out and verify the target URL. Amplified across thousands of sites, this swarms the victim’s server with junk traffic and drains your server’s outbound bandwidth.
How to Test if Your Site Exposes XML-RPC
To check your site’s status, append /xmlrpc.php to your root domain in any browser:
[https://yourdomain.com/xmlrpc.php](https://yourdomain.com/xmlrpc.php)
If the browser displays:
“XML-RPC server accepts POST requests only.”
Your XML-RPC endpoint is actively responding to requests and open to automated probes.
How to Safely Disable XML-RPC
You can shut down XML-RPC at either the server level or the application level.
Method 1: Web Server Level (Recommended)
Blocking traffic at the server level stops requests before PHP or WordPress ever executes, saving server memory and CPU cycles.
For Apache (.htaccess)
Place these directives at the very top of your .htaccess file, outside the # BEGIN WordPress block:
Apache
# Block public access to xmlrpc.php
</Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>
For Nginx
Add this location rule inside your active server block configuration:
Nginx
# Block access to xmlrpc.php
location = /xmlrpc.php {
deny all;
return 403;
}
Reload Nginx afterwards using sudo systemctl reload nginx.
Method 2: Application Level (WordPress Hook)
If you do not have direct access to server configuration files, add this snippet to your theme’s functions.php file or via a code snippets plugin:
PHP
// Disable XML-RPC functionality in WordPress
add_filter(‘xmlrpc_enabled’, ‘__return_false’);
This filter stops WordPress from executing XML-RPC authentication, but the server will still boot the PHP runtime to return the response during an attack. Server-level blocking remains the better option for high-traffic or resource-constrained environments.
Method 3: Security Plugins & WAFs
Most security suites provide simple toggle controls:
- Wordfence: Navigate to Login Security > Settings and enable “Disable XML-RPC authentication”.
- Patchstack / Sucuri: Enable edge rules and virtual patching to block incoming XML-RPC traffic at the firewall level.
Exceptions to Consider
Before disabling XML-RPC completely, make sure your site does not depend on these workflows:
- The WordPress Mobile App: The app requires XML-RPC to publish and manage content.
- Jetpack Connections: Jetpack relies on XML-RPC to communicate with WordPress.com servers. (Note: You can whitelist Jetpack IP ranges in your firewall or
.htaccessif you need to keep it running.) - Pingbacks/Trackbacks: Legacy cross-blog notifications will stop functioning.
Leaving xmlrpc.php exposed is essentially bolting the front entrance while leaving the side door unlocked. If your workflow does not explicitly require Jetpack or the mobile app, dropping a quick block rule into your server configuration eliminates a major vector for brute-force attacks and wasted server overhead.