June 17, 2020
June 17, 2020
WordPress has always had inbuilt features that let you remotely interact with your site. Face it, sometimes you’ll need to access your 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.
Take your WordPress site to the next level and get a secure WordPress hosting solution with Hostinger today!
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.
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.
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.
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.
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.
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 and install the plugin that looks like the image below:
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.
If you’d want to only turn certain elements of XML-RPC off, but still allow certain plugins and features to work, then use the following plugins instead:
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>
Note: Change xxx.xxx.xxx.xxx to IP address you wish to allow access xmlrpc.php or remove this line completely.
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.
August 05 2018
It was really helpful. I don't even know about this file. Now, I will disable the file. Thanks a lot.
January 27 2019
Thank you! No need to take a plugin for this little issue, I've done it per htaccess. One question: Just delete this file is not a solution?
Replied on September 24 2019
Hey meisterleise, Just deleting the file is not a solution because it will be recreated after WordPress update.
April 16 2019
I'm an artist and not a tech, so I had a few portfolio sites that were successfully hacked by brute force (from weak passwords). I lost all my work on the site, as I didn't have a backup before the hack- meaning I've been educating myself on how not to let this happen again. I changed the default login, but am still getting attacked by this file. This page was exactly what I needed to understand what this file does, and how to disable it- thank you for writing it in plain English for those of us- less qualified. Jim
July 02 2019
Thank you much. My sites on a worldwide "hit list" on a regular basis. Through Wordfence I can watch them hitting me. Thanks to this code it stopped instantly - Perfect <3
July 22 2019
Thanks a lot!
September 02 2019
September 09 2019
I am really satisfied on your describe about xmlrpc I got 400 hundreds brute force attack. Now I'm disabled this file as you mentioned👌
December 05 2019
I've moved away from .htaccess and am putting rules directly in my httpd.conf file for apache. This article was great, as I am getting hundreds of brute-force attempts on my site, and I've entirely blocked access to this file now. My site doesn't allow logins other than those from my company, so I'm actually also limiting wp-login.php to only IP addresses from my company. Thanks for the info!
January 16 2020
This was very helpful, thank you! Following a recent hack on company websites, and I noticed a lot of visitors trying to access this file on our sites. I added your lines to my .htaccess and my resource usage dropped to a normal level, stopped them at the door! What a relief!
May 15 2020
I am posting this, hoping it can be useful for someone. My system started behaving erratically to the point of having to reboot it several times. I have 5 wordpress installations running; when I checked what tasks were active, I saw thousands of php-cgi tasks from all the different wordpress users. I then tail -f /var/log/apache2/suphp_log and noticed endless petitions to the damn xmlrpc.php file. Then I started editting .htaccess for each one of the sites, adding the code you wrote, and the system normalized. Thanks for your help!