Wordfence and XML-RPC

Correct. If we get enough feedback we may consider removing the disable by default and just keeping it as an option.

Regards,

Mark.

Ooh, I’m glad I found this post because I’ve already spent way too much time thinking about why I could no longer create new blog entries from within Adobe Lightroom – as I always have been able to before.

Thanks to this post, I have switched on XML in the Wordfence Options so that everything works as it should again. The information on this new update should be somewhat clearer… ??

This tripped me up too. At the very least there should have been some comment that XML-RPC would be disabled by default in the latest version and perhaps a note that if users were having trouble using external apps that setting might fix the problem.

Sorry about that guys, we’ll probably modify the next version to leave XMLRPC enabled by default, although it’s too late for you now. Thanks for the feedback and sorry for any inconvenience.

Regards,

Mark.

I’ll accept your apology for the inconvenience. I spent a lot of time trying to resolve my issue of not being able to post remotely with one of my remote posting programs.

It didn’t occur to me that Wordfence may have been causing the issue or I would have come to this support forum first.

After hours upon hours of frustration of trying to figure it out myself I asked the tech support from my VPS host to look into my issue for me.

Wordfence is the only plugin that shows such a recent modification time. I recommend disabling the Wordfence plugin and attempting to make another post via the XMLRPC API. If the post works with this plugin disabled, then we can safely assume Wordfence is causing the problem.

All is well that ends well. I came here to determine if I would need to delete Wordfence completely until the issue was resolved and I’m happy to see it is as simple as unticking an option.

This is unfortunately an improper fix and has no tangible benefit for WordPress users.

The changelog says “Disable XML-RPC in WordPress to prevent your site from being used as a drone in a DDoS attack.” The problem is this “attack” affects pingbacks. But the fix actually disables everything in XML-RPC except pingbacks, thus breaking mobile apps and anything else relying on XML-RPC, but allowing pingbacks through.

If you want to disable pingbacks, then disable pingbacks. Don’t do this. Or don’t do anything, as these attacks are not particularly effective and more recent versions of WordPress and Akismet both pass along better information when verifying pingbacks; and Akismet additionally detects abuse.

Andrew Nacin’s analysis rings true to me. But In the future with any changes that alter the advertised behavior of a standard WordPress installation, you could get the best of both words, so to speak, by making a point of preserving existing behavior *for updated installations*. I don’t think it would be too bad to default to whatever you think is best for new installations, because those users will be able to strongly correlate installing your plugin with whatever the change in behavior is.

Andrew: I’ve filed a bug against this and we’ll investigate.

Regards,

Mark.

Would appear that it’s also prevented the latest version of Woo Commerce updating.

My host told me

“you installed wordfence, and we are not responsible for bad coding from wordfence and you need to fix that on that plugin you installed
check for WordFence plugin settings and try to disable the ‘Disable XMLRPC’ feature of the plugin.”

Options – More Options – and unchecking the XMLRPC box

has seemingly done the trick

Actually on reflection, it wasn’t necessary to include the quote from my hosting company, and I don’t see that it adds anything to the above post other than to provoke.

The observation that the Woo Commerce plug in is affected however is valid, as seems to be the instruction for resolving (in my case) but if someone could remove the unecessary quoted bit that serves no useful purpose I’d be grateful (I have tried to find a moderator contact but have so far failed)

Thanks

Hi all,

We’ve yanked the feature. I’ve just released Wordfence 5.0.3 and the only difference is that we’ve completely removed the ability to disable XML-RPC.

I’ve also put up a blog entry here explaining what we’re doing to prevent this from happening in future:

https://www.wordfence.com/blog/2014/04/removing-the-ability-to-disable-xml-rpc-in-emergency-release-5-0-3/

In short: We screwed up. We’re sorry. Clearly our release process and quality assurance isn’t keeping up with the growth in Wordfence’s user base and the sites that depend on us. So we need to fix this internally and I can assure you we’re going to improve the process.

Thanks to everyone including Andrew Nacin and all posters above who weighed in on this.

Regards,

Mark Maunder.

Hi Mark,

Thank you for your active participation in the discussion and quick response! Things happen. I guess we’re all glad that this “bug” didn’t ruin our websites, mess with the tables or files, and just caused a little delay to figure out what happened.

Regards,
Andrey

Am I reading this wrong Mark?

“We’ve yanked the feature. I’ve just released Wordfence 5.0.3 and the only difference is that we’ve completely removed the ability to disable XML-RPC.”

Surely it was the fact that we could to disable XML-RPC that allowed us to install the update (Woo in my case, as I operate a Woo theme). If your update removes this capacity, won’t the issue return?

Sorry?!?!?

I use this feature and I know what that it means, but if I update to 5.0.3 I loose even the possibility of disabling XML-RPC with your plugin and must disable it by hand or search for another plugin.

Please put the option back, disabled if you want, but I think it’s very useful to leave the option.

@andrew Nacin:
Then having Akismet active and up to date is ENOGUH to be protected from this kind of DDoS?