XML-RPC and Why It’s Time to Remove it for WordPress Security

From the very beginnings of WordPress, there have been features that allow you to interact remotely with your site. These same features build your community by allowing other bloggers to reference your posts. At the core of all of this is XML-RPC.

XML-RPC, or XML Remote Procedure Call, powers these features in WordPress:

Connecting to your site(s) with your smartphone

Trackbacks and pingbacks when other sites refer to your site

Jetpack

But there’s a problem with XML-RPC that you need to resolve to secure your WordPress site.

What Is XML-RPC and What Is It Used For?

Back in the early days of blogging (long before WordPress existed), most writers on the Internet were still using dial-up connections to surf the web. It was hard to write posts and get them up. The solution was to write on your computer offline and copy/paste your prose, and perhaps a graphic or two to your blog. Folks who were using a word processor found this method somewhat troublesome, as their text often had extraneous codes attached, even if you saved a document as HTML.

Blogger created an application programming interface (API) to allow other developers to access Blogger blogs. Enter the offline blog client, which allowed users to type posts offline and then connect to Blogger API-enabled blogs through XML-RPC. Other blogging systems followed suit, and there was eventually a MetaWeblogAPI that standardized basic access.

Jumping forward a decade or so, today we all use apps on our phones and tablets instead of our computers. One of the things that people like to do with their phones is post to their WordPress sites. In 2008-09, Automattic obliged by creating WordPress apps for pretty much every mobile operating system (even Blackberry and Windows Mobile).

These apps allowed you, through the XML-RPC interface, to use your WordPress.com credentials to log in to any WordPress site you had user rights to.

This happens by way of the Remote Procedure Calls – that is what RPC stands for.

And now you should be thinking “Oh, no. What happens if someone else gets my password?” The answer isn’t pretty: that “someone else” can do everything you can do on your site. Because, of course, they are effectively you. Getting a queasy feeling yet?

More bad news: If you use Jetpack to use its wonderful tools on your self-hosted site, several of those wonders use XML-RPC too.

History: Should XML-RPC Stay or Go in WordPress?

XML-RPC support has been part of WordPress from the first day. If you want to be fussy about it, it’s part of the pre-history of WordPress; being part of the b2 platform that Matt Mullenweg forked to create WordPress.

WordPress 2.6 was released on July 15,2008. Enable XML-RPC was added to the WordPress Remote Publishing settings, with the default setting set to “Off.”

A week later, the WordPress for iPhone app was released, and its users were asked to flip the setting to “On.”

Four years after the iPhone app joined the family, WordPress 3.5 made XML-RPC support enabled by default and took away the dashboard setting.

And so it has stayed.

The main weaknesses associated with XML-RPC are:

Brute force attacks: Attackers try to login to WordPress using xmlrpc.php with as many username/password combinations as they can enter. A method within xmlrpc.php allows the attacker to use a single command (system.multicall) to guess hundreds of passwords. Daniel Cid at Sucuri described it well in October 2015: “With only 3 or 4 HTTP requests, the attackers could try thousands of passwords, bypassing security tools that are designed to look and block brute force attempts.”

Attackers try to login to WordPress using xmlrpc.php with as many username/password combinations as they can enter. A method within xmlrpc.php allows the attacker to use a single command (system.multicall) to guess hundreds of passwords. Daniel Cid at Sucuri described it well in October 2015: “With only 3 or 4 HTTP requests, the attackers could try thousands of passwords, bypassing security tools that are designed to look and block brute force attempts.” Denial of Service Attacks via Pingback: Back in 2013, attackers sent Pingback requests through xmlrpc.php of approximately 2500 WordPress sites to “herd (these sites) into a voluntary botnet,” according to Gur Schatz at Incapsula. “This gives any attacker a virtually limitless set of IP addresses to Distribute a Denial of Service attack across a network of over 100 million WordPress sites, without having to compromise them.”

Convenience vs WordPress Security, Yet Again

So here we go again. The modern world is deeply annoying with its trade-offs.

If you want to make sure no one is bringing a bomb on your airplane, you have to stand in line to go through the metal detectors. If you want to keep your car while you’re shopping, lock the doors and close the windows. You can’t use [email protected] to lock your website, either. Especially if you like using Jetpack or the mobile apps.

What Can I Do About XML-RPC Security?

Understand that the security issue isn’t really XML-RPC itself, the problem is that attackers can use this as another way to brute-force its way through to your username and password. So the best way to protect yourself is (still) to use long, complicated passwords (or use a password manager that can create them for you). But that isn’t always easy to do, particularly if you engage with WordPress through several different computers.

The next best thing you can do to protect yourself today is to turn off XML-RPC in your Settings altogether. Some additions to your .htaccess file can lock down access to the xmlrpc.php file. Here’s how to do that.

Note: Check with your web host for their policy on users creating and editing .htaccess before making changes.

Check for an existing .htaccess file. Your web host documentation may point you in the right direction. If none exists, create the file in the htdocs/wordpress folder.

Open the file in a text editor and add the following code near the top:

You can simplify this process by installing and activating the Disable XML-RPC plugin.

Disabling xmlrpc.php shuts down every tool that uses this file. You can still use WordPress on your phone or tablet. Instead of the mobile apps, you can

Partially Disabling XML-RPC in WordPress

So you have become dependent on all these tools that are, in turn, dependent on XML-RPC. I really get that you don’t want to turn XML-RPC off, even for a little while.

Here are some plugins that can help:

Stop XML-RPC Attack: Only allows Jetpack and other Automattic tools to access xmlrpc.php through .htaccess.

Only allows Jetpack and other Automattic tools to access xmlrpc.php through .htaccess. Control XML-RPC Publishing: Simply restores the old Remote Publishing option to the Settings > Writing menu.

menu. iThemes Security, Anti-Malware Security and Brute-Force Firewall and All in One WP Security & Firewall: These general-purpose security tools include brute-force protection in their free tier. They watch for repeated attempts to log in, with or without xmlrpc.php and ban sites that appear to be trying to break in. I’ve successfully used the iThemes tool for several years now.

I’ll note that one major security plugin, Wordfence, decided against disabling XML-RPC. In a blog post, mark wrote:

To us, disabling XML-RPC comes with a cost. You are disabling a major API in WordPress. We briefly provided this capability, but removed the feature because WordPress’s own API abuse prevention has improved. Furthermore, providing the ability to disable XML-RPC caused confusion among users when their applications broke because they could not access the API.

REST (and OAuth) to the Rescue

Now you may already know that the WordPress core developers are turning WordPress’s code into a REST application. The developers on the REST API team have had some issues getting ready, including with the authentication piece intended to resolve the XML-RPC problem. When this finally happens (currently planned for v4.7 at the end of 2016), you won’t have to use XML-RPC to use the mobile apps or Jetpack.

Instead, you’ll authenticate yourself in external apps through the OAuth protocol. You may not know what OAuth is, but if you’ve ever clicked a Twitter button on a post, you’ve used OAuth.

When you click the social sharing button, a secure HTTPS screen comes up and asks you to identify yourself to Twitter, Facebook, LinkedIn or whomever. You enter your username and password for that site, and you can share that post. The owner of the WordPress site doesn’t know your social site’s password, and no one can intercept that data while it’s being sent.

The social app then places a cookie in a browser with a key and secret that allows the remote site to connect for a designated period of time. Then you don’t have to enter your credentials for the life of that cookie.

Here’s why OAuth is better, safer and more wonderful than XML-RPC: Fundamentally, you don’t have to share your password in plain text over the Internet for your mobile app to connect to your site.

The REST API team are working on an “”Authentication Broker” that will allow connections to any of the multitudes of WordPress sites.

Testing the WordPress REST API

As I said earlier, the REST API is not yet integrated into WordPress core, and won’t be for months. Today, you can begin playing with it on your non-production sites. To do this:

In the meantime, you have to make your own decisions about the convenience/security tradeoff continuum.

Tags: