Securing WordPress by Disabling XML-RPC Pingbacks

WordPress has a very convenient functionality that allows it to be manipulated through external sources using the xmlrpc.php file. Using this, you can administer your site via a mobile application that communicates with your blog through a different interface. It also allows programs like Microsoft’s Live Writer blogging software to post updates to your blog without having to actually login directly.

In addition, XML-RPC is used by a number of plug-ins – most notably Jetpack which I personally recommend to every self hosted WordPress blog or for its numerous “all-in-one” functionality. Finally, the XML-RPC protocol is also used for pingback notifications when another site links to you.

However, it has recently been found that it can be exploited to be part of a massive DDoS attack. A hacker can essentially use your xmlrpc.php file to send multiple requests to a victim target URL. This was recently used in a famous attack noted by the protection service Sucuri which was used to bring down a large popular website. In this article, we look at the various ways in which you can prevent your own xmlrpc.php file from being exploited in this manner. The options will range from the nuclear to the surgical.

Method 1 – Simply Delete or Rename xmlrpc.php

This approach is the “nuke it from orbit” solution. If you’re pretty sure that you’re not going to ever require XML-RPC via plug-ins or any other kind of third-party interaction with your website, you can get rid of the file entirely either by deleting or renaming it. It’s located in the root directory of your WordPress installation.

However, this is only a temporary solution as future updates to the core WordPress files will simply reinstate it. Given that you can never tell whether or not a future plug-in or functionality on your website will require xmlrpc.php, I can’t really recommend the solution. It’s not permanent and it’s too drastic. Moreover if you do manage to keep the file off your server, you have no record that you did so and might easily forget about it.

Method 2 – Disallow Using .htaccess

This solution involves accessing your WordPress .htaccess file and inserting the following code:

<files xmlrpc.php>
	Order allow,deny
	Deny from all
</files>

This will simply block all access to xmlrpc.php. Anyone who tries to use it will receive a 403 forbidden error message. The advantage of this solution over the previous one is that subsequent WordPress updates will not modify it. Moreover, there’s a concrete record that you have denied access to xmlrpc.php. Meaning that it might occur to you to reverse the change when you’re troubleshooting some problem.

However, it will still break all XML-RPC functionality on your website including the Jetpack plug-in.

Method 3 – Disable via functions.php

This is similar to the second solution except that you make the change in functions.php instead of .htaccess. Open up your themes functions.php and paste the following before the closing ?> PHP tag:

add_filter('xmlrpc_enabled','__return_false');

Obviously it’s slightly more inefficient than the previous solution because it’s being handled at the application rather than the server level. On the other hand since functions.php is where you place most of your custom code anyway, you’re more likely to be reminded of what you’ve done. And this still doesn’t address the problem of losing all XML-RPC services.

Method 4 – Disable only Pingbacks

This is the most surgical solution to the problem. Instead of removing all XML-RPC functionality, we only disable the pingback service which causes all of the security problems in the first place. As above, insert the following into your functions.php file:

function disable_xmlrpc_ping ($methods) {
   unset( $methods['pingback.ping'] );
   return $methods;
}
add_filter( 'xmlrpc_methods', 'disable_xmlrpc_ping');

This code removes the pingback parameter from the $methods argument passed to our custom function. It will ensure that your site cannot be used as part of a larger botnet participating in a DDoS attack.

If you’re keen on retaining XML-RPC capability on your WordPress blog, I recommend the fourth method. If you want to ignore XML-RPC entirely, you have to choose one of the others depending on whether you want to prioritize efficiency or good coding practices.