Introduction
If you have ever examined your WordPress site’s access logs and noticed a relentless stream of POST requests directed at a file named xmlrpc.php, you are witnessing one of the most common vectors for automated attacks on the web. While WordPress is the world’s most popular Content Management System (CMS), its ubiquity makes it a primary target for hackers. One of the oldest and most frequently exploited vulnerabilities isn't actually a bug, but a legacy feature: XML-RPC.
In this guide, we will dive deep into what XML-RPC is, why it poses a significant security risk to your WordPress installation, and how disabling it can drastically reduce your server's CPU load. Whether you are a developer managing high-traffic sites or a business owner looking to harden your security, understanding how to manage this protocol is essential for a stable, high-performance hosting environment.
What is XML-RPC?
XML-RPC (XML Remote Procedure Call) is a protocol that allows WordPress to communicate with external applications. It was introduced long before the modern WordPress REST API existed. Historically, it was the primary way for mobile apps, desktop editors, and other remote systems to interact with your site. Features like pingbacks, trackbacks, and remote publishing through the WordPress mobile app all relied on this protocol.
When you post a comment on a blog and it automatically notifies the other blog you linked to, that’s a pingback powered by XML-RPC. When you use the official WordPress mobile app to upload a photo while on the go, it traditionally used XML-RPC to authenticate and transfer the data. However, as web technology evolved, XML-RPC became increasingly redundant, eventually being superseded by the much more secure and flexible WordPress REST API.
Why is XML-RPC a Security Risk?
Despite its utility in the past, XML-RPC has two major flaws that make it a favorite for malicious actors: brute force attacks and Distributed Denial of Service (DDoS) vulnerabilities.
1. Brute Force Attacks via system.multicall
Standard login forms are relatively easy to protect. You can use CAPTCHAs, two-factor authentication, or limit login attempts. However, XML-RPC features a method called system.multicall. This function allows an attacker to attempt hundreds of username and password combinations in a single HTTP request.
Instead of making 500 individual requests to wp-login.php (which would be easily flagged by a firewall), a bot can send one single request to xmlrpc.php containing 500 sets of credentials. This makes brute force attacks significantly more efficient for the attacker and much harder for basic security plugins to detect and block.
2. Amplified DDoS Attacks via Pingbacks
XML-RPC also enables pingbacks. An attacker can use thousands of legitimate WordPress sites to launch a DDoS attack against a single target. By sending a specially crafted request to your xmlrpc.php file, they can trick your server into sending a request to a third-party URL. When thousands of WordPress sites do this simultaneously, the target server is overwhelmed by traffic originating from "legitimate" sources, making the attack incredibly difficult to mitigate.
The Performance Impact: Saving Your CPU
Beyond security, XML-RPC is a resource hog. Every time a bot hits your xmlrpc.php file, WordPress has to initialize its entire core, connect to the database, and process the XML request. Even if the login attempt fails, the server still spends cycles processing that request.
On a typical unmanaged VPS, a sustained XML-RPC brute force attack can spike CPU usage to 100%, causing your legitimate visitors to experience slow load times or "Error Establishing a Database Connection" messages. By disabling XML-RPC at the server level, you stop these requests before they even touch the WordPress core, freeing up your CPU for actual customers.
Is XML-RPC Active on Your Site?
You can easily check if your site has XML-RPC enabled by using an online validator or a simple command-line tool. If you have access to a terminal, run the following curl command:
curl -D- "https://yourdomain.com/xmlrpc.php"
If you see a response that says "XML-RPC server accepts POST requests only," the protocol is active. If you receive a 403 Forbidden or 404 Not Found error, it is already disabled.
How to Disable XML-RPC
There are several ways to disable XML-RPC depending on your technical comfort level and hosting environment.
Method 1: Using a Plugin (The Easy Way)
For users who prefer not to touch code, the "Disable XML-RPC" plugin is a popular choice. Once installed and activated, it adds a filter to your site that turns off the protocol. However, keep in mind that this still allows the request to reach your WordPress installation before it is denied, meaning it doesn't provide the maximum performance benefit.
Method 2: Disabling via .htaccess (Apache Servers)
If your host uses Apache, you can block access to xmlrpc.php before WordPress even loads. Add the following code to your .htaccess file:
# Block WordPress xmlrpc.php requests
<Files xmlrpc.php>
order deny,allow
deny from all
</Files>
This is much more efficient than using a plugin because the server rejects the request at the entry point.
Method 3: Disabling via Nginx (Modern Hosting)
Most high-performance managed hosts, including XeroWP, use Nginx. To disable XML-RPC in Nginx, you need to add a location block to your site configuration:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}
This configuration completely drops the request and ensures it isn't even logged, saving both CPU and disk I/O.
Method 4: Using a PHP Filter
If you want to disable it within your theme or a custom functionality plugin, you can use the built-in WordPress filter. Add this to your functions.php file:
add_filter( 'xmlrpc_enabled', '__return_false' );
Note: This will stop the functionality but will not prevent the server from processing the initial request.
What Happens When You Disable XML-RPC?
Before you pull the trigger, it is important to know what might break. For 99% of modern WordPress sites, the answer is: nothing. However, there are a few exceptions:
- The WordPress Mobile App: Older versions of the app relied on XML-RPC. Modern versions use the REST API, but some legacy features might still require it.
- Jetpack: Some Jetpack modules (like Publicize or the site management dashboard) use XML-RPC to communicate with WordPress.com. If you use Jetpack, you might need to leave XML-RPC enabled or use a plugin that only allows Jetpack-specific IPs to access it.
- Third-Party Automation: Tools like IFTTT or Zapier that post to your blog via older integrations might fail.
If you use the REST API for your integrations, you are completely safe to disable XML-RPC.
The Modern Alternative: WordPress REST API
Since WordPress 4.7, the REST API has been the standard for remote communication. It is faster, more secure, and follows modern web standards (JSON instead of XML). Almost every modern plugin and mobile app has migrated to the REST API. Unlike XML-RPC, the REST API is designed with robust authentication methods and doesn't suffer from the same multicall vulnerabilities.
Conclusion
Disabling XML-RPC is one of the most effective "quick wins" for WordPress security and performance. It shuts down a major avenue for brute force attacks and prevents your server from wasting precious CPU cycles on bot traffic.
At XeroWP, we prioritize your site's security and speed. Our managed hosting environment is optimized to handle these threats at the infrastructure level, ensuring your WordPress site remains fast and secure without you having to worry about the underlying server configuration. If you're tired of managing security patches and server spikes, consider switching to a managed platform that does the heavy lifting for you.
