It’s Time for XML-RPC in WordPress to Hit the Road


Jesse Nickles Founder of Little BizzyThis post was contributed by Jesse Nickles. He is the founder of LittleBizzy, a managed WordPress hosting company, and a part-time blogger at CollegeTimes, where he gets into trouble exploring controversial issues.


Two weeks ago, I announced that all current and future domains hosted at LittleBizzy would have XML-RPC permanently blocked due to the non-stop problems it was causing. In the announcement, we recommended that other WordPress users across the globe urgently consider blocking the technology on their own web servers as well.

XML-RPC in WordPress Has a Troubled Past

Days after the announcement, Daniel Cid, founder and CTO of Sucuri, and Mark Maunder, CEO of WordFence, confirmed the reports that a new type of Brute Force login attack was being carried out on a massive scale against WordPress sites around the world using XML-RPC. Apparently, hackers have wised up to the fact that wp-login.php is often well protected.

Perhaps more shocking than this latest wave of attacks is that they are nothing new, as Sucuri previously reported a similar wave of attacks in July 2014. Let’s also not forget the wide-scale use of XML-RPC to perform DDoS attacks on WordPress websites reported by Incapsula in 2013. Combine these reports with hundreds of posts on the wordpress.org support forums and Stack Overflow and a picture is painted of years of unhindered attacks against millions of WordPress sites due to this single PHP file, yikes!

It is common sense to take a method and try it. If it fails, admit it frankly and try another. But above all, try something. ― Franklin D. Roosevelt

I didn’t expect to be the one to advocate that XML-RPC be removed from WordPress but that’s exactly what I’m doing: It’s time for WordPress XML-RPC to hit the road, for good.

XML-RPC Was a Conscious Mistake

I understand that thousands of volunteer hours have been invested into XML-RPC support for the WordPress platform, as is the nature of open-source communities. I sincerely respect and thank said programmers and volunteers for creating a very cool way to remotely connect to a website built on WordPress. But sometimes, we need to be honest with ourselves and admit when something isn’t working; This one of those times.

If you’re wondering why I’m framing the XML-RPC mess as a conscious mistake, that’s because it was. Three years ago, Andrew Nacin, a WordPress core developer, announced in a trac ticket that, “Security is no greater a concern than the rest of core. There is no longer a compelling reason to disable [XML-RPC] by default. It’s time we should remove the option entirely.”

Three years later, millions of WordPress sites have been hacked, crashed, or attacked, due to XML-RPC. It’s undeniable that removing the option to disable it (and/or enabling it by default) was wrong.

Out of Touch With the Average User

When broken down, it’s a classic case of extremely talented and intelligent software developers being out of touch with the millions of average Joes that use WordPress and have no idea what XML-RPC is. When developers inevitably argue that there are several free security plugins available that can help combat XML-RPC attacks, they completely miss the point: the majority of webmasters being attacked are the same ones who don’t even know what a security plugin is or how to use it.

Ironically, the one good standalone plugin that fought Brute Force login attempts was foolishly combined into the controversial Jetpack plugin, which most serious webmasters would never consider installing.

The premise, of course, for XML-RPC support in WordPress is a noble idea that sounds versatile: it allows, as previously mentioned, remote connections (logins, usually) to any given domain that is running a WordPress installation. In reality, however, this XML-RPC functionality is primarily used for three common reasons:

  1. Pingbacks/trackbacks (great for Viagra spam, DDoS attacks, and not much else)
  2. Jetpack (an all-in-one solution to slowing down and/or bloating your WordPress site with third-party scripts)
  3. WP mobile apps (I’m not sure who blogs from their smart phone, but the YO app is literally rated higher than WordPress on the iTunes store, and the user reviews of the Android version repeatedly point to XML-RPC login issues)

Do recall that the WordPress backend is now responsive, which means you can login to your blog from practically any mobile device; this wasn’t the case when the native WordPress mobile apps were first launched. And arguably, the vast majority of WordPress sites have absolutely no use for pingbacks, trackbacks, or XML-RPC in general.

XML-RPC Needs to Be Disabled or Removed From WordPress

The logical conclusion should be immediately clear: XML-RPC needs to die a quick death in the WordPress community, or at least be shifted into an optional (non-default) plugin or otherwise, in order to bring an immediate and measurable improvement to the security and stability of not only WordPress sites, but the internet overall.

Perhaps Jeff Chandler said it best:

WP Tavern is no stranger to denial of service attacks due to pingbacks and trackbacks. In 2010, I explained how WP Tavern was trackbacked to death. Shortly after the website came back online, I disabled both as I feared they might end up taking the site down again. A few years have gone by and I’ve re-enabled pingbacks and trackbacks with no ill effects. However, I wonder if it’s time to kill them once and for all, not just on WP Tavern but in WordPress in general.

Sometimes, we as developers and others with a technical mindset get caught up in solving the challenge of the day, when what is really needed is to step back and take a more philosophical look at the bigger picture. Is this thing worth our time, or is it causing more problems than solutions? When it comes to XML-RPC in WordPress, the conclusion is obvious.

There are 63 comments

Comments are closed.