What is XMLRPC and How This WordPress' Vestigial Tail Threatens Your Website Security

In the root directory of every WordPress site is a file, xmlrpc.php that actually predates WordPress itself. Back before WordPress, during the b2 days, this file was created to give sites a way to communicate with each other and for other applications to communicate with the blog itself.

What is XMLRPC?

The name tells you everything you need to know about the functionality.

XML – This was designed to accept payloads in XML. These days JSON is a much more common format but XMLRPC predates JSON by quite a bit.

RPC – RPC stands for Remote Procedure Call. It was a standard by which one system could ask another system to do something. These days we use APIs – REST or Graph API – to do the same thing but before those existed, RPC was one of the ways we accomplished this.

How does XMLRPC work?

To make XMLRPC.php do something you had to POST a message to it. If you are not familiar with how browsers work, this is basically like clicking the Submit button on a form. That usually initiates a POST request. 

If you make a POST request to yourdomain.tld/xmlrpc.php and you hand it a properly formatted XML payload, you can do things like create a post on your site.

One of the things that XMLRPC was used for a lot back in the day was “pingbacks”. Those comments you see on posts that show that someone else linked to it on their blog. 

Potential security threats from WordPress’ XMLRPC

For a long time, XMLRPC was a useful tool. Those days are fading into history now. These days all of the functionality that XMLRPC used to be used for is handled by the built-in REST API. Even though it’s not used anymore. It’s still hanging around. Those who get nostalgic about such things see it and smile. Those that are worried about security see it and frown.

XMLRPC poses a couple of distinct security risks for WordPress sites that can result in severe WordPress XMLRPC attacks. 

• Brute Force Attacks via XMLRPC

The first type of WordPress XMLRPC attack is a simple Brute Force attack. Since part of the XML payload that is passed to WordPress is the login and password of the user that wants to take the action, it is an easy way for attackers to try out user name and password combos until they find one that works. Many security conscious site owners will limit the number of login attempts a user can make before locking them out but won’t bother to block XMLRPC requests thus leaving a back-door open for attackers to try and find a way in.

Once an attacker finds credentials that work, they are free then to attempt to do damage to your site by injecting content into your site’s database. Whether these are Posts, Pages, or just comments, the end result is the same. Content that you did not approve and most likely do not want is being served by your site. 

At the very least, this means spam comments or posts. At the worst though, it could be innocuous posts or comments that have malware injected.

• DDoS attacks using XMLRPC

Because one of the ways that XMLRPC was used was for pingbacks, malicious users can use it to overwhelm your server by issuing a lot of expensive requests all at once.

A pingback writes a record to your database. Writing to your database is an expensive task, resource wise. While a single pingback won’t hurt your site’s performance, hundreds or even thousands of them at once can bring even the beefiest server to its knees. 

This is called a DDos or Distributed Denial of Service attack. Distributed because it’s usually not a single machine making all the requests, usually it is a whole bunch of machines spread out all over the place.

How to disable XMLRPC in WordPress

There are a few ways you can disable XMLRPC. I highly recommend that you do it because honestly, you just don’t need it. 

• Through your webserver’s config file 

If you are familiar with how to block requests via your webserver’s config files – and you have access to your webserver’s config files, this is a great way to block it. For Apache, you can add this code to the .htaccess file in the root directory of your site.

<Files xmlrpc.php>

order deny,allow

deny from all

</Files>

That will stop it dead in its tracks.

• Through your theme’s functions.php file

If you are not one who likes to much around in your web server’s config files, you can add a single line of code to your theme’s functions.php file.

add_filter( ‘xmlrpc_enabled’, ‘__return_false’ );

Make sure and get that exactly right, there are 2 underscores before the word return. Again, this will turn it off. This tells WordPress itself that you don’t want to accept XMLRPC requests.

• Installing a plugin

Finally, if don’t want to bother with adding code to your theme’s functions.php, you can disable XMLRPC in WordPress by installing a plugin. (Hint, the plug does the exact same thing as the previous tip.) There are several good ones out there that are free or you may already have this functionality available to you if you have one of the Application Firewall plugins installed.

If not, let me recommend my favourite one and what I use on all of my sites to turn off XMLRPC, SiteGround Security Plugin. Even if you aren’t hosting with SiteGround, you can use this free plugin to manage several different security tasks. If you only want it to turn off XMLRPC, then disable all the other options. That’s one of the things I love about this plugin, everything is optional.

XMLRPC served us well in it’s day, but it’s day has come and gone. It’s time to let it retire gracefully. Until the WordPress core developers decide it is time to remove it, you need to protect yourself and your site by disabling it.