What is WordPress XML-RPC and How To Stop an Attack

The WordPress XML-RPC is a specification that aims to standardize communications between different systems. It uses HTTP as the transport mechanism and XML as encoding mechanism which allows for a wide range of data to be transmitted.

For us WordPress peeps, the most important part of this is “different systems”. WordPress needs to communicate with other systems from time to time and until recently XML-RPC was the best candidate for the job. When communicating with other blogging systems like Blogger or Movable Type, or when posting from desktop clients or the official mobile apps, XML-RPC was, and still is, there to help.

Why all the past tense? Very soon the new WP API will take its place, which is a RESTful API bringing more flexibility, better security and all-round happiness to the table. However, since WordPress is all about backwards compatibility, XML-RPC will be around for a long long while, so we may as well get acquainted with it!

The History of WordPress XML-RPC

Do you know when WordPress first implemented XML-RPC? Version 3.4, 2.1, perhaps as far back as 1.2? Nope, trick question, it was a part of the original b2 blogging software, which WordPress was forked from. This is back when the zipped version was 268kb and there were more files and folders beginning with “b2” than “wp”.

The logic behind the whole system was contained in the xmlrpc.php file in the root directory. It contained functions such as wp_insert_post(), wp_delete_post() and so on.

XML-RPC was off by default originally, you had to go to Settings > Writing > Remote Publishing to enable it. Since version 3.5 the functionality is on by default.

XML-RPC Today

After going through a number of changes, the size of this file decreases from 83kb to just 3kb, most of the functionality is now tucked away in a neat little class. This class is called wp_xmlrpc_server and can be found in wp-includes/class-wp-xmlrpc-server.php and contains 48 WordPress functions, 7 Blogger functions, 6 MetaWeblog functions, 8 MovableType functions and 4 functions for pingbacks.

As I said earlier, these aren’t very well documented so you’ll need to open up this file and take a look at the class yourself. There’s also a Tuts+ article on coding with XML-RPC in mind, but that’s basically it.

XML-RPC in the Future

The advent of the new WP API will see the downfall of XML-RPC. The WordPress API can already be used, but requires a plugin activation and is still in its test phase. Not too far in the future, it will be a part of the WordPress core code, which is when it will start to encroach on XML-RPC territory.

At the moment, there are some features that the WordPress API is still lacking, although it is way more powerful in other ways that XML-RPC. Take a look at the excellent comparison on the WP API website.

The Problems With XML-RPC

The two biggest assets of the API is its extendability and its security. XML-RPC authenticates with basic authentication. It sends the username and password with each request which is a big no-no in security circles.

The WordPress API can use Oauth which never sends your username and password, it uses tokens for authentication, making it a lot more secure.

In addition, the functions and methods don’t have to be hard-coded into the specific implementation. You can (already) add your own endpoints to create anything you want, you aren’t restricted to just adding posts, managing taxonomies and users, etc.

While you can extend XML-RPC as well, the process is not documented well and is not as powerful as its API counterpart.

JSON vs XML is another argument where the XML-RPC may fall short. The API uses JSON to send and receive data which is favored by developers due to its ease of use in both server and client side languages. XML can get a little tricky, requiring PHP classes to read properly.

Last, but not least, in the past years XML-RPC has become and increasingly large target for brute force attacks. This has nothing to do with any security vulnerability and everything to do with yet another path into WordPress. When using XML-RPC to make calls you need to supply a username and password and the system will confirm when you hit a valid pair.

Making XML-RPC Better

If you don’t use XML-RPC at all, perhaps the best thing you can do is disable it. There is a free plugin named Disable XML-RPC which will do just that. The premium plugin Perfmatters (developed by a team member at Kinsta) also allows you to disable XML-RPC along with other optimizations for your WordPress site.

Or you can do this with code by adding the following to a plugin or theme (this is definitely plugin territory though):

add_filter( 'xmlrpc_enabled', '__return_false' );

The other issue you can prevent is brute force login attempts. These plugins will lock down the login once a couple of failed attempts have been made. All In One WP Security And Firewall is a more elaborate plugin that does this, but you can use some more specific tools like Login Lockdown. I like to use more specific plugins myself, to decrease my plugin footprint.

Check XML-RPC On Your WordPress Site

Not sure if XML-RPC is currently running on your website? Danilo Ercoli, from the Automattic team, wrote a little tool called the XML-RPC Validator. You can run your WordPress site through that to see if it has XML-RPC enabled. If it doesn’t, you will see a failure message such as shown in the image below on the Kinsta blog.

How to Stop a WordPress XML-RPC Attack

At Kinsta, when an attack through XML-RPC is detected a little snippet of code is added into the nginx config file to stop them in their tracks – producing a 403 error.

location ~* ^/xmlrpc.php$ {
return 403;
}

Summary

In my opinion, the WordPress XML-RPC was a great system, but it’s time to move on to the WP API. Due to backward compatibility developers should still know about, and be able to use, XML-RPC, but it will become less and less popular over time.