XML-RPC is a protocol designed for WordPress to standardize communication between different systems, allowing external applications (such as other blogging platforms and desktop clients) to interact with WordPress. This feature has been a part of WordPress since its early days, enabling seamless integration with the rest of the online world.
However, the xmlrpc.php file, which is responsible for implementing the XML-RPC protocol in WordPress, has its drawbacks. It can introduce vulnerabilities to your WordPress site and has now been largely replaced by the more advanced and secure WordPress REST API, which also facilitates communication between WordPress and other applications.
In this article, we will discuss what xmlrpc.php is, why disabling it can improve your website’s security, and how to determine if it’s currently active on your WordPress site.
What is the xmlrpc.php file?
XML-RPC is a protocol that facilitates communication between WordPress and other systems by standardizing these interactions, utilizing HTTP for transport and XML for encoding. This specification predates WordPress itself, as it was initially present in the b2 blogging software, which eventually evolved into WordPress in 2003. The code for this system resides in a file named xmlrpc.php, located in the root directory of a WordPress website. Although XML-RPC is now largely outdated, it continues to exist in WordPress installations.
In the early iterations of WordPress, XML-RPC was disabled by default. However, starting with version 3.5, it became enabled by default to allow the WordPress mobile app to communicate with WordPress installations. Before this version, users needed to enable XML-RPC on their websites for the mobile app to post content, as the app functioned as a separate entity communicating with the WordPress site via xmlrpc.php.
XML-RPC was not limited to the mobile app; it also facilitated communication between WordPress and other blogging platforms, enabled trackbacks and pingbacks, and powered the Jetpack plugin connecting self-hosted WordPress sites to wordpress.com. However, with the integration of the REST API into WordPress core, the use of xmlrpc.php for communication has become obsolete — the REST API offers significantly more compatibilities and flexibility.
Due to the REST API’s broader capabilities and its replacement of XML-RPC, it is now recommended to disable xmlrpc.php on your website to mitigate risk. Let’s explore the reasons for this change.
Reasons to disable xml-rpc.php on WordPress
With the advent of the REST API, XML-RPC is no longer needed for external communication in WordPress, making it wise to disable it as it can introduce security vulnerabilities and be the target of various attacks.
Let’s delve deeper into the specific vulnerabilities associated with the xmlrpc.php file.
Brute force via xmlrpc.php
Brute force attacks involve hackers attempting to gain access to a website’s backend by trying thousands of username and password combinations until they find the correct credentials. Websites with weak admin passwords and lacking multi-factor authentication are particularly vulnerable to such attacks.
Attackers can use automated tools to find and list all valid usernames for a website. Once they have this information, they can exploit the xmlrpc.php file to carry out a brute force attack by sending requests with various password combinations. If a website’s security measures are inadequate, hackers don’t even need to bypass reCaptchas or worry about limited login attempts. This could potentially allow hackers to gain unauthorized access to your site, posing a significant security risk to your WordPress environment.
So, if you’re currently using a version of WordPress that leverages the REST API to communicate with external systems, it’s worth disabling XML-RPC entirely to mitigate risk.
DDoS attacks via xmlrpc.php
Distributed Denial of Service (DDoS) attacks can completely incapacitate your server by sending thousands of simultaneous requests. In WordPress, hackers often use the pingback feature in conjunction with the xmlrpc.php file to execute DDoS attacks. These attacks can overload your server and take your site offline by using xmlrpc.php to send a massive number of pingbacks in a short time.
To initiate the attack, hackers first identify a target page and verify the presence of the xmlrpc.php file by sending a specific request. Once they confirm its existence, they start bombarding it with pingback requests from a network of compromised websites.
In many instances, this process can be automated using specific code, which allows hackers to send numerous pingback requests to the target site. As a result, disabling xmlrpc.php can significantly reduce the risk of DDoS attacks and help maintain a secure environment for your WordPress website.
How to check if XML-RPC is enabled on WordPress
To determine whether XML-RPC is active on your WordPress website, you can use curl. Send a request to the XML-RPC endpoint, which is usually found at https://site-url-example/xmlrpc.php.
Follow the example below to execute this task:
bash curl -X POST -d '<?xml version="1.0" encoding="iso-8859-1"?><methodCall><methodName>system.listMethods</methodName><params></params></methodCall>' -H 'Content-Type: text/xml' 'https://site-url-example/xmlrpc.php'
This command sends a POST request to the XML-RPC endpoint, along with an XML payload that invokes the system.listMethods method. If XML-RPC is enabled, this method will return an array of accessible XML-RPC methods.
If XML-RPC is active, you will obtain an XML response that includes a list of available methods. If XML-RPC is deactivated or the endpoint is non-existent, you will receive an error message or a non-XML response.
Note: There are lots of free services on the web that offer to check XML-RPC for you. But it’s possible that these online testers are using these web apps to farm a list of websites, so it’s not recommended to use them - especially when you can just use curl instead.
How to disable XML-RPC on WordPress
There are a number of different options you can leverage to disable XML-RPC on your WordPress website, including modifications to your .htaccess file, disabling it with a filter, or installing a plugin.
Disable XML-RPC via .htaccess file
If you use Apache, you can disable XML-RPC by editing your .htaccess file to include the following code:
<Files xmlrpc.php> Order Allow,Deny Deny from all </Files>
Ensure you create a backup of the original .htaccess file before making any changes. Note that if you use NGINX web server instead of Apache, and will not have a working .htaccess file. In this case, try one of the other methods to disable XML-RPC.
Disable XML-RPC via plugin filter
To manually disable XML-RPC on your WordPress website, you can create a custom filter by writing your own site-specific plugin (or adding it to an existing one). In the plugin, include the following line of code:
add_filter( 'xmlrpc_enabled', '__return_false' );
While it’s possible to add this code to your theme’s functions.php file instead, it’s a better idea to create a plugin. This is because any modifications made to the functions.php file may be lost when updating or changing your theme.
Why hasn’t XML-RPC been removed from WordPress?
You might be wondering why XML-RPC hasn’t been removed from WordPress altogether. The answer lies in one of WordPress’s key features: backward compatibility. While it is essential to keep your WordPress, plugins, and themes up-to-date, there will always be website owners who are unwilling or unable to update their WordPress versions. Older versions that predate the REST API still require access to xmlrpc.php.
To wrap things up, XML-RPC was once a vital component for communication between WordPress and external applications, but its usefulness has declined with the introduction of the more secure and versatile WordPress REST API. Although xmlrpc.php still exists in WordPress installations due to backward compatibility, it’s important to recognize that keeping it active can bring security risks such as brute force and DDoS attacks.
So, take a moment to check if XML-RPC is enabled on your WordPress site. If you no longer need it, go ahead and disable it to help mitigate risk from brute force and DDoS.
And if you’re looking for a web application firewall to help block bad bots, virtually patch known vulnerabilities, and further harden your environment, you can check out our free 30 day WAF trial to give it a try.