I can’t believe I’m writing this post. But, I am.
This concerns something in WordPress that a lot of people don’t even know is there called XML-RPC. The XML-RPC feature has been turned on by default since version 3.5 (released 2012 December 11) and which I think has been in WordPress itself since the beginning even if not enabled by default.
Without getting too technical, XML-RPC is responsible for two main features of note: pingbacks and external blog post editor support. Unfortunately, it has recently become the vector of choice for what I can only assume is some kind of worm/malware which sends thousands of requests in an attempt to either break into a site or just plain cause havoc and increased resource usage. That’s where the problem begins.
This wouldn’t be that vexing of a problem except for one thing: I actually use XML-RPC legitimately. This post, for example, was made via the XML-RPC function, not WordPress’s internal editor (though I have made posts via the internal editor before). Most of the posts you’ve seen me make in the last three years have had the XML-RPC interface come into play during editing at some point. So, just turning this thing off isn’t an option.
I tried a couple of plugins which promised to “secure” XML-RPC and they did so by completely breaking it. (I can do a better job of this with “rm xmlrpc.php” or “chmod go-rx xmlrpc.php” myself, I don’t need a plugin to effectively do something like this for me.) It is difficult to know for sure, but given the relatively low traffic I have, it does not make sense that my resource usage is what it is. (Resource usage which I pay for, I might add.)
So, what the h-e-double-hockey-sticks am I, or other WordPress site admins, supposed to do?
Well, right now (actually, by the time I post this, as of a couple of weeks ago), my solution is akin to a duct-tape-quality fix: copy the existing xmlrpc.php to something else, and use that for my editor’s XML-RPC endpoint. It’s the only thing I could think of to do, and thankfully almost everything still appears to work as designed.
I say “almost” because this doesn’t yet solve the problem of legitimate pingbacks potentially getting dropped. My host has XML-RPC protection, but unfortunately that protection is to change permissions on xmlrpc.php at the first sight of an attack (breaking the functionality until I manually restore it). Unfortunately I don’t have a way to tell sites sending me pingbacks to send them somewhere else automagically just yet. It also means I have to repeat this step on each upgrade (well, at least if xmlrpc.php changes). Like most actual duct tape repairs, it’s probably not the best solution. But, for now, it works, and to me that’s what matters.