WordPress has always had inbuilt features that let you remotely interact with your site. Face it, sometimes you’ll need to access your WordPress website and your computer won’t be anywhere nearby. For a long time, the solution was a file named xmlrpc.php. But in recent years, the file has become more of a pest than a solution.
Below we dive into what xmlrpc.php actually is and why it was created. We also overview the common security issues it causes and how to patch them on your own WordPress site.
What Is Xmlrpc.php?
XML-RPC is a feature of WordPress that enables data to be transmitted, with HTTP acting as the transport mechanism and XML as the encoding mechanism. Since WordPress isn’t a self-enclosed system and occasionally needs to communicate with other systems, this was sought to handle that job.
For example, let’s say you wanted to post to your site from your mobile device since your computer was nowhere nearby. You could use the remote access feature enabled by xmlrpc.php to do just that.
The core features that xmlrpc.php enabled were allowing you to connect to your site via smartphone, implementing trackbacks and pingbacks from other sites, and some functions associated with the Jetpack plugin.
Why Was Xmlrpc.php Created and How Was It Used?
The implementation of XML-RPC goes back to the early days of WordPress before it even became WordPress.
Back in the early days of the internet, when the connections were incredibly slow, the process of writing and publishing to the web was much more difficult and time-consuming. Instead of writing within the browser itself, most people would write offline, then copied and pasted their content onto the web. Still, this process was far from ideal.
The solution (at the time), was to create an offline blogging client, where you could compose your content, then connect to your blog to publish it. This connection was done through XML-RPC. With the basic framework of XML-RPC in place, early apps used this same connection to allow people to log in to their WordPress sites from other devices.
XML-RPC Nowadays
In 2008, with version 2.6 of WordPress, there was an option to enable or disable XML-RPC. However, with the release of the WordPress iPhone app, XML-RPC support was enabled by default, and there was no option to turn off the setting. This has remained true to the present day.
However, the functionality of this file has greatly decreased over time, and the overall size of the file has decreased from 83kb to 3kb, so it doesn’t play as large of a role as it used to.
The Future of XML-RPC
With the new WordPress API, we can expect XML-RPC to be eliminated entirely. Today, this new API is still in the trial phase and can only be enabled through the use of a plugin.
However, you can expect the API to be coded directly into the WordPress core in the future, which will mostly eliminate the need for the xmlrpc.php file altogether.
The new API isn’t perfect, but it provides a more robust and secure solution to the problem that xmlrpc.php addressed.
Why You Should Disable Xmlrpc.php
The biggest issues with XML-RPC are the security concerns that arise. The issues aren’t with XML-RPC directly, but instead how the file can be used to enable a brute force attack on your site.
Sure, you can protect yourself with incredibly strong passwords, and WordPress security plugins. But, the best mode of protection is to simply disable it.
There are two main weaknesses to XML-RPC which have been exploited in the past.
The first is using brute force attacks to gain entry to your site. An attacker will try to access your site using xmlrpc.php by using various username and password combinations. They can effectively use a single command to test hundreds of different passwords. This allows them to bypass security tools that typically detect and block brute force attacks.
The second was taking sites offline through a DDoS attack. Hackers would use the pingback feature in WordPress to send pingbacks to thousands of sites instantaneously. This feature in xmlrpc.php gives hackers a nearly endless supply of IP addresses to distribute a DDoS attack over.
To check if XML-RPC is running on your site, then you can run it through a tool called XML-RPC Validator. Run your site through the tool, and if you get an error message, then it means you don’t have XML-RPC enabled.
If you get a success message, then you can stop xmlrpc.php with one of the two approaches below.
Method 1: Disabling Xmlrpc.php With Plugins
Disabling XML-RPC on your WordPress site couldn’t be easier.
Simply navigate to the Plugins › Add New section from within your WordPress dashboard. Search for Disable XML-RPC-API and install the plugin.
Activate the plugin and you’re all set. This plugin will automatically insert the necessary code to turn off XML-RPC.
However, keep in mind that some existing plugins may utilize parts of XML-RPC, so disabling it completely could cause a plugin conflict or certain elements of your site to no longer function.
Method 2: Disabling Xmlrpc.php Manually
If you don’t want to utilize a plugin and prefer to do it manually, then follow this approach. It will stop all incoming xmlrpc.php requests before it gets passed onto WordPress.
Open up your .htaccess file. You may have to turn on the ‘show hidden files’ within file manager or your FTP client to locate this file.
Inside your .htaccess file, paste the following code:
# Block WordPress xmlrpc.php requests <Files xmlrpc.php> order deny,allow deny from all allow from xxx.xxx.xxx.xxx </Files>
Important! Change xxx.xxx.xxx.xxx to IP address you wish to allow access xmlrpc.php or remove this line completely.
Conclusion
Overall, XML-RPC was a solid solution to some of the problems that occurred due to remote publishing to your WordPress site. However, with this feature came some security holes that ended up being pretty damaging for some WordPress site owners.
To ensure your site remains secure it’s a good idea to disable xmlrpc.php entirely. Unless you require some of the functions needed for remote publishing and the Jetpack plugin. Then, you should use the workaround plugins that allow for these features, while still patching the security holes.
In time, we can expect the features of XML-RPC to become integrated into the new WordPress API, which will keep remote access and the like, without sacrificing security. But, in the meantime, it’s a good idea to protect yourself from the potential XML-RPC security holes.
Have you blocked XML-RPC access via a plugin or manually? Or experienced any security issues from having it active in the first place? Please share your experience in the comments below.
