Skip to content

WordPress XMLRPC.php, What is it and how to protect it?

Taking advantage of the impact that the attacks against WordPress XMLRPC.php are having, I would like to clarify certain concepts related to this file that is part of WordPress and step by step explain how to protect against possible brute force attacks and denial of service against this file in a WordPress installation.

As we’ve talked a lot on this blog lately, many WordPress installations are falling victim to various attacks in different ways: on the one hand there are malware infections or code injections and on the other hand there are external attacks against some parts of WordPress such as the xmlrpc.php file or wp-login.php.

In this article we are going to go by parts, we are going to go explaining certain basic and interesting aspects on the subject, since many speak in their blogs about the attacks to XMLRPC.php but very few know what is the XMLRPC protocol or the function that makes the XMLRPC.php file in WordPress.

What is XMLRPC?

The XMLRPC protocol is a protocol that uses XML to structure data and the HTTP protocol for the transmission of that data structured in XML.

The XMLRPC protocol was developed in 1998 by UserLand Software in collaboration with Microsoft, finally Microsoft considered that the XMLRPC protocol was very simple and turned it into what is now called SOAP.

In WordPress, the current XMLRPC protocol as an interface that acts as an API for external applications and allows us to interact with a WordPress installation using external applications or services.

As it works as an external interface it is almost like an “entrance door” so this door can be easily attacked from the outside causing a high consumption of resources by running over and over the authentication process.

WordPress and XMLRPC.PHP

As we said before, in WordPress the XMLRPC protocol is managed by the XMLRPC.php file that you can find in the root of the WordPress installation:

To communicate with a WordPress installation using the XMLRPC protocol we must send HTTP requests via POST to the xmlrpc.php file located at the root of the installation, with this we will get an answer.

If everything has gone well normally the response obtained is HTTP/1.1 200 OK.

Until version 3.5 WordPress had the XMLRPC protocol disabled by default, since version 3.5 is enabled by default, and there is the problem, since all installations have the XMLRPC protocol enabled and by default are vulnerable to denial of service and brute force attacks against this protocol.

Let’s give several examples of REAL functions that the XMLRPC protocol does in WordPress:

  • The XMLRPC protocol allows desktop programs such as Microsoft Word, Textmate or Mozilla Thunderbird to communicate with our WordPress installation.
  • The XMLRPC protocol allows communication via pingbacks and trackbacks with other blogs or other WordPress installations.
  • The XMLRPC protocol is the one that allows certain functions of the Jetpack plugin to work for WordPress that has direct communication with the Automattic servers.

Possibly I have something else left in the inkwell that can be done with XMLRPC.php, but in principle the ones mentioned above are the main ones.

Protection against attacks to XMLRPC

There are several methods to protect against XMLRPC attacks, and although none of the methods is 100% effective, they do help maintain the stability of the installation even if they attack us, obviously the more resources we have available on our server or in our hosting plan, the more room for maneuver we will have in case they attack us because we will have more resources.

The first protection method consists of making several modifications in several WordPress files so that the XMLRPC.php file is not found and also to deactivate the XMLRPC functionalities so that WordPress does not show any error for it.

The first thing we are going to do is to delete or change the name of the XMLRPC.php file that we will find in the root of our installation:

The next thing we have to do is go to our WordPress wp-config.php file (also found in the root of the installation) and below the last line we place the following:

add_filter(‘xmlrpc_enabled’, ‘__return_false’);

The next thing we have to do is go to the funcions.php file of the theme we have activated and at the end we have to add the following code:

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

This method is quite simple, but for users not used to WordPress and the web world can be somewhat difficult, for that reason there are other methods to disable the XMLRPC.php and prevent them from attacking us.

Protection against XMLRPC attacks – Method 2

This second method is simple. It does the same as method 1 but in an automated way and taking advantage of the possibilities that plugins have in a WordPress installation.

We will use the XMLRPC Attacks Blocker plugin. It is a free plugin that can be downloaded directly from the repository of WordPress plugins and allows you to disable XMLRPC.php almost completely.

You can find more information about this WordPress plugin at the following URL: https://es.wordpress.org/plugins/xmlrpc-attacks-blocker/

The advantage of this plugin is that we could even select a single user to which we will allow access through the XMLRPC protocol, in addition, it allows us to block through the .htaccess to all IP addresses that try to use our XMLRPC.php file once deactivated the protocol.