Recent Update To Wordfence Security Breaks WordPress Mobile Apps

With the release of WordPress 3.8.2, some users are reporting on the WordPress.org support forum that the update disabled XML-RPC causing mobile apps to break. Many of those who are reporting the issue have one thing in common: they’re using the Wordfence Security plugin. With over 1.5 million downloads, Wordfence Security is a popular plugin used to secure WordPress sites.

Wordfence Security Plugin Header

A recent update to Wordfence disables XML-RPC in WordPress to prevent sites from being used as drones in a pingback Denial of Service attack. Due to the timing of WordPress 3.8.2 as well as the update to Wordfence, users think 3.8.2 is the culprit. Andrew Nacin, lead developer for WordPress, replied to the support thread explaining why the fix is improper and has no tangible benefit to 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.

Wordfence responded, saying they’ve filed a bug and will be investigating a fix. Until then, if you’re using Wordfence, browse to the plugin’s options page and look for Other Options. Uncheck the box to Disable XML-RPC for DDoS protection.

Upgrade WordPress and Akismet To The Latest Versions

Network Solutions recently sent out a security bulletin to customers using WordPress informing them about the Denial of Service attacks that can result from pingbacks. Network Solutions advised customers to install the Disable XML-RPC plugin. While it disables the XML-RPC API, it does not disable trackbacks and pingbacks.

The best course of action is to update to WordPress 3.8.2 if you haven’t already done so. Also upgrade Akismet to the latest version. Both software updates address the Denial of Service attack associated with pingbacks without having to disable XML-RPC entirely.

12 Comments


  1. Hi Jeff
    I don’t use this plugin but I did take a look at it on wordpress.org and noticed…

    “The following video is an introduction to Falcon Engine, the new caching engine included in Wordfence 5 which will make your site up to 50 times faster than a standard WordPress installation.”

    I wondered if anyone had activated the Falcon Engine on their site and tested the speed increase.

    Report


    1. I use Wordfence but decided against activating the Falcon Engine. We also use WP Super Cache and as far as I can tell, the “50 times faster” in FE is as a result of htaccess caching as opposed to PHP caching. Super Cache works well enough for us in that regard.

      Report


    2. The “falcon engine” is a solution to a problem that shouldn’t exist if security was done correctly. That is, if security was placed here as it should be for optimal performance and effectiveness:

      Attacker => HTTP server => PHP => **Security** => WordPress => Plugins

      There would be no need to cobble together a separate caching solution and introduce yet another break point as wordfence has done.

      But since security is placed after wordpress and after plugins, coming late to the party as it were, then they are left scrambling to fix a problem that they themselves created.

      The only security/firewall that I’m aware of that does it correctly and blows all the current security plugins out of the water is ninja firewall. Here are benchmark comparisons with the 5 most popular security plugins showing the difference:
      http://nintechnet.com/wordpress-brute-force-detection-plugins-benchmarks.html

      ps I am in no way related to ninja, its creators, etc. just a wordpress user who is more and more surprised every day that no one makes mention of this critical difference in how security is done and how it should be done.

      Report


      1. Thanks for making me aware of Ninja, after further research I’ve decided to trial this as another security layer basedon the reviews and the logic.

        Report


      2. Classic case of believing something someone told you (or a pretty graphic) and not really verifying the information as fact. .htaccess files are processed first before PHP code since htaccess files are distributed server configuration files. Then the Ninja plugins claims are false. I don’t think this is intentional. I think they honestly believe their WAF is processed first which is incorrect/not valid.

        Report


      3. Comment edited for you. Darn, really gotta get the site fixed so the comment editing plugin works.

        Report


  2. I use the plugin on every site I build out. Currently there is only one site that I cannot login to via the mobile app – my business site (I love a diet rich in irony :) ) – but it doesn’t appear to be XMLRPC related. I don’t use any caching plug-ins – never saw a reason to do so.

    Report


  3. Hi Jeff,

    After receiving this feedback from our users and the WP community including Andrew Nacin we’ve put out a release 5.0.3 which fixes this issue. We’ve completely yanked the feature. I’ve also published a blog entry here explaining what we’re going to do to prevent this from happening in future:

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

    Regards,

    Mark Maunder – Wordfence founder.

    Report


    1. These things happen and it’s a delight to see your quick and gracious response Mark.

      Report


      1. Thanks Keith. It sure has been a crazy week. A major Wordfence release with the associated hiccups, then heartbleed on Monday which is probably the worst vulnerability we’ve all seen for years, then JetPack yesterday.

        Dare I say TGIF? Probably best not to tempt fate.

        Report


  4. Regarding the Disable XML_RPC plugin, as the plugin author, I did not realize that it was being recommended for this use by Network Solutions. I have also found a couple of other articles relating to the DDoS attack that mention it as a way to thwart the attack.

    The plugin was not designed for the purpose of disabling pingbacks. It does one very simple thing – set the “xmlrpc_enabled” filter to false. This filter was introduced in WordPress 3.5, when the UI option to disable XML-RPC was removed and it was enabled by default. I had some edge cases where a site owner did not need or want remote publishing and wanted XML-RPC disabled to lessen his security footprint. I decided to release the plugin to the repository, in case anyone else found it useful.

    I regret that Network Solutions and others publicized it to do something that it doesn’t. I can only assume that it was not fully tested for this use case before that e-mail was sent.

    Report

Comments are closed.