What Is xmlrpc.php in WordPress and Why You Should Disable It
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.
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.
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?
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!
August 18 2020
Nice write up, thanks. I've been disabling XMLRPC via Asset Cleanup and also adding a Cloudflare firewall rule for double protection. However, there is an even easier way. Just go to PHP Confuguration in hPanel and uncheck the XMLRPC checkbox. To recap: 1. Add a firewall rule in Cloudflare to partially/fully restrict access - best option if you still use XMLRPC. 2. Disable XMLRPC via Asset Cleanup or similar plugin (saves having lots of smaller plugins). 3. Safest method is to disable XMLRPC in Hostinger hPanel. Stay safe, guys, because XMLRPC does get a lot of hacking attempts if you check Cloudflare dashboard.
September 04 2020
If i try to login to the wordpress app, it shows "couldn't connet. Required XML-RPC methods are missing on the server'. What is this? Anyone knows?
November 11 2020
Hey there Lahiru. Are you hosting your website with us? If you do, please message our Customer Success team to help you out with this.
October 24 2020
I do have major security issue on one of my websites. My home page and other blog pages are injected with foreign scripts. Tried various malware removal apps like wordfence, scuri, malcar and many more, Nothing works. It get automatically inserted to wordpress cache every time malicious code was removed. Finally decided to block my xmlrpc file. Now everything work fine.
February 02 2021
Happy to hear you were able to resolve it!
November 29 2020
Thanks Kevin Wordfence showed constant attacks using this file - interestingly from all over the world
February 09 2021
Happy this helped resolve it!
December 15 2020
Great solution to an age old problem. Changing the .htaccess file may the better solution, no extra plugins. Thanks.
December 22 2020
This was really handy. I've only just set up a new blog and it's literally days old, so there's nothing there except a banner "Under Construction". Yet my WordFence has alerted me to many attempts over the last few days to access xmlrpc.php. So I went ahead and used method 2 in my cpanel and voila, it's now giving 404 when I try to access xmlrpc.php through a private browsing session. Thanks a lot.
January 10 2021
Hi, Thanks a lot, I too had problem with my website. I though I almost lost all my work. Thanks to hostinger's weekly backup. I deleted all the existing files and restored my website from the backup. Even after that, the attack was happening. Finally after searching a lot found this article. I now disabled access to the xmlrpc.php file by adding the code to .htaccess. Once again thanks a lot for this document.
March 31 2021
Excellent article just what i needed to read. I have a firewall on my site but these brute force attacks just choke up your site and slow everything down. I changed my default login address ages ago but was unaware the xmlrpc access was such an issue. 345 attempts from one IP address aimed at wp-login.php and xmlrpc.php today each one accessed as a group every minute. Im going to go ahead and deactivate it now
May 20 2021
Thanks so much for the info. My site has been getting hit with a barrage of phishing via xmlrpc. I have been wasting time everyday deleting and monitoring and..... I added the code using .htaccess file. Keeping my fingers crossed that I will see this issue end.
June 04 2021
Thanks for this. Someone managed to crash my site using this, so I have now disabled it.
August 21 2021
Thanks for this! One of my sites has been getting a lot of xmlrpc.php SPAM comments and I just did the check and I will be turning off xmlrpc.php. My second site is newer, has not yet been attacked so strongly, but I am fixing that as well. Thank you so much for this information!
September 16 2021
I am hoping that you just solved an extremely infuriating issue for this old school designer. I started noticing strange traffic and abnormal bandwidth issues on my site and was very surprise to find all the PHP files hosted all over multiple WP sites. Sadly the hi jacked pages get more traffic than any of my sites ever do - they are mainly for small businesses. I decided to clean them up manually which turned into something I had to schedule weekly because no matter how much I secured my site, these pages were still showing up. Tonight as I was cleaning it up, I searched Xmlrpc.php to see if it was a part of the word press install or just one more file that they have added. I came across this aticle and promptly went and added the code to all of my .htaccess files. Only time will tell. Now I need to go develop an exciting 404 page for all this search engine traffic I get from my hijacked site. I had never seen it before but keep good tabs on my site stats so the URLs and traffic are all well documented.
September 21 2021
Hi Jen, wishing you all the best in battling those bad guys! Keep us updated on how it goes :)
October 17 2021
Thanks a lot. My site was having lot of attempt login on XML RPC and your post has help a lot now. Much Appreciated.
October 19 2021
Happy to hear you were able to resolve it!
January 26 2022
I got a message from my server (Siteground) that this file contains malicious information, so I reached your article and quickly manually disabled it. Thanks!
February 04 2022
Happy it worked out for you, Eran!