This post was originally submitted as a guest piece to WP Tavern, and is re-published here in its original form.
It was just 2 weeks ago that I wrote a blog post announcing that all current and future domains hosted at LittleBizzy would have XML-RPC permanently blocked due to the non-stop problems it was causing, and recommending other WordPress users across the globe to urgently consider blocking the technology on their own web servers as well.
Literally days later, Daniel Cid from Sucuri and Mark Maunder from WordFence confirmed reports that a new type of Brute Force login attack was being carried out on a massive scale against WordPress websites around the world using XML-RPC as an entry point, as hackers have apparently wised up to the fact that
wp-login.php is often well protected these days.
But perhaps more shocking than this latest wave of attacks is that they are nothing new. Indeed, Sucuri previously reported a similar wave of attacks in July 2014. And let’s not forget the wide-scale use of XML-RPC to perform DDOS attacks on WordPress websites as reported by Incapsula back in 2013. Combine these with other reports, and the hundreds and hundreds of posts on wordpress.org, Stack Overflow, and elsewhere, and a picture is painted of years upon years of unhindered attacks against millions of WordPress websites due to this single little 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
Truly, I didn’t expect to be writing a public call for the abandonment of XML-RPC in WordPress so soon — but here we are now, and that is exactly what I’m doing: It is time for WordPress XML-RPC to hit the road, for good.
I do understand that thousands and thousands of volunteer hours have been invested into XML-RPC support for the WordPress platform, as is the nature of open-source communities. I do 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, it’s simply time to be honest with ourselves and admit when something isn’t working; indeed, folks, this is one of those times.
If you are wondering why I’m framing the XML-RPC “mess” as a conscious mistake, that’s because it was. 3 years ago the WordPress 3.5 core team 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.”
3 years onward, with millions of WordPress sites hacked, crashed, or attacked, it is undeniable that this was wrong.
When broken down, it is a classic case of extremely talented and intelligent software developers being out of touch with the millions of “average Joes” that actually use the WordPress software and have no idea what XML-RPC even is. When devs inevitably argue that, “But wait! There are several free security plugins out there that can help combat XML-RPC attacks!” they completely miss the point: the majority of webmasters getting 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 DID fight Brute Force logins 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 3 common reasons:
a) pingbacks/trackbacks (great for Viagra spam, DDOS attacks, and not much else)
b) Jetpack (an all-in-one solution to slowing down and/or bloating your WordPress site with third-party scripts)
c) WP mobile apps (I’m not sure who blogs from their smartphone, 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)
The WordPress backend is completely “responsive” now, meaning that you can login to your blog from practically any mobile device (which wasn’t the case when the native WordPress mobile apps were first launched). And it goes without saying that the vast majority of WordPress websites have absolutely no use for pingbacks, trackbacks, or XML-RPC in general.
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 websites, but the internet overall.
Perhaps Jeff Chandler said it best: “WPTavern is no stranger to denial of service attacks due to pingbacks and trackbacks. In 2010, I explained how WPTavern 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 WPTavern but in WordPress in general.”
Sometimes we as developers and others of technical mind get caught up in solving the challenge of the day, when what is really needed is a step back and a more philosophical look at the bigger picture. “Is this worth our time? Is this causing more problems than solutions?” When it comes to XML-RPC in WordPress, the answers are obvious.