Update WP Super Cache and W3TC Immediately – Remote Code Execution Vulnerability Disclosed

  • April 23, 2013

Shame on us for not catching this a month ago when it was first reported, but it seems that two of the biggest caching plugins in WordPress have what we would classify a very serious vulnerability – remote code execution (RCE), a.k.a., arbitrary code execution:

…arbitrary code execution is used to describe an attacker’s ability to execute any commands of the attacker’s choice on a target machine or in a target process. – Wikipedia

It appears that a user by the name of kisscsaby first disclosed the issue a month ago via the WordPress forums. As of 5 days ago both plugin authors have pushed new versions of their plugins disabling the vulnerable functions by default. The real concern however is the seriousness of the vulnerability and the shear volume of users between both plugins.

There are a few posts, released within the past few hours that do a great job of explaining what the issue was and what was being exploited. You can find some good after action thoughts on Frank Goosens’ blog and on Acunetix’s blog as well.

Why Such a Big Deal?


Between the two plugins they’re looking at something close to 6 million downloads, granted not all current and some will be updates, but assuming even 25% are unique sites that’s an impressive number for any plugin. The real issue comes in that it applies to any WordPress blog that has comments enabled.

If you’re using a third-party service, like Disqus, this won’t affect you. A really simple way to test is leave yourself a comment like this:

<!–mfunc echo PHP_VERSION; –><!–/mfunc–>

If it works, it’ll show you something like this:

Screen Shot 2013-04-23 at 5.17.32 PM

You can see that it’s showing the version of my server’s PHP install. No big deal right? Wrong. This means I can pass any commands I want to your server and they’ll execute, hence the term remote command execution (RCE).

In this instance all I said was echo, or print out, the version of my PHP, in it of itself is benign. Replace my echo with an eval and encode a payload and now it’s a different ball game. Case in point, a backdoor shell, all while going via your comments and bypassing all other authentication controls.

Again, not an issue to be taken lightly, this is a very serious vulnerability, further exacerbated by the fact that any user can exploit it. The easiest way to protect yourself is to upgrade. You can find the latest updates on the WordPress.org repository:

Kudos to the plugin developers for acting quickly on the issue. Now it’s your turn end-users, update!

Tony is the Head of Security Products at GoDaddy and Sucuri Co-Founder. His passion lies in educating and bringing awareness about online threats to business owners. His passions revolve around understanding the psychology of bad actors, the impacts and havoc hacks have on website owners, and thinking through the evolution of attacks. You can find his personal thoughts on security at perezbox.com and you can follow him on Twitter at @perezbox.

56 comments

  1. Supreme bummer here.

    In cases like this, I’d think plugin developers should be able to remotely disable plugins on user’s site, auto-email admins of a site, and force them to upgrade before reactivating the plugin.

  2. That is the first thing I saw when I logged into numerous sites. Thanks for a more detailed explination boys.

  3. Batcache FTW! … http://wordpress.org/extend/plugins/batcache/

    I always found to hard to figure out what was going on inside WP Supercache and W3 Total Cache. There’s too much code to read through, so I switched to Batcache since the code is much much simpler and easier to understand.

    I don’t like using plugins if I don’t have time to do a full security audit on them as problems like this tend to occur.

  4. What do I do with the payload has already been deployed into my app? Which logs do I have to check, if any?

    1. Restore from backup, then manually back in any comments or posts which may have been added since your last backup. Make sure you update the plugin before pushing the changes live, or you risk being hacked again before you have a chance to upgrade the plugin.

    2. tested comments on my site(s) running quick cache, and it just displayed the text as entered instead of executing it.

  7. Are you sure? WP Super Cache was updated around 12 days ago and the plugin author mentions only the following in change log

    1.3.1

    Minor updates to documentation
    Fixed XSS in settings page.

  8. Don’t update wp-super-cache, delete it. The author hasn’t removed the arbitrary code execution vulnerability, they just blacklisted some naughty strings in comments. If you’re using BuddyPress, for instance, you can just put the naughty strings in forum posts instead of comments.

  9. WP Super cache still says most recent update was 1.3.1? There is also no notice in the plugins panel to upgrade either? How do we know the plugin has been updated? (sorry Yogesh – I didn’t see your comment) Does this include ANY type of form plugin or just comments?

    1. Well I tried out the echo commend mentioned above and it showed up as it was written i.e. it didn’t get executed.

    2. Version 1.3 fixed the issue of mfunc tags in comments.
      Version 1.3.1 fixed a minor XSS bug.
      Version 1.3.2, released today, disables the mfunc tags entirely, since almost nobody actually uses them, and adds a config option for people who do use them.

  10. Good grief! I’m glad we got rid of W3TC a while ago because we found (after quite a bit of investigation) that it assumes it’s the only thing using your Memcached server, and periodically tries to flush all the keys out of memory.

  11. We just got rid of WP Super Cache last week on the blog I’m partners with and we’re working on in house version of our own. But this is great news that you guys are right on top of these kind of scary things. Thanks for posting!

  15. Wow, can’t believe this was left untreated for a month. Luckily I use cloudflare and they updated their system to prevent this from happening. I’ll still be upgrading to the new version of W3TC right now.

  18. Regular plugin updates is the only way.. at least once a week.. Better safe than sorry 🙂

  24. Never used any of this caching plugins, my site is pretty light anyway and has some great page load times since moving to my new server. Will share the post to give some more exposure on the vulnerabilities.

  28. So, How do I update W3TC? When I go to the admin page and then to the plugin repository it doesn’t give me the option to update. I tried deactivating but that didn’t work. Do I have to delete the old W3TC plugin and start from scratch?

  29. when i am checking in wordpress dashboard plugin the wp super cache and w3tc are not shown over there. In that condition am I safe with the vulnerability.

  32. Having used the WordPress plug-in W3 Total Cache on several of my clients sites, I was concerned to see that there was some pretty serious security exploits. Two days ago, all of my clients who are on BlueHost experienced problems with the minification, in that it just stopped working and this caused their websites to load without any sort of style sheets. Since I also have a change tracking plug-in installed called Simple History, I went to look at what had been done lately and I saw these entries

    Plugin “W3 Total Cache” activated
    2 days ago by

    Plugin “W3 Total Cache” deactivated
    2 days ago by

    This wasn’t me, or any other user registered for my sites. One of my ideas for this is that the plug-in author somehow pushed an update along, or maybe BlueHost did some script on all their sites. I don’t know, and I’m looking for some answers as to how this happened. Can anyone help me?

  33. This plugin still has multiple vulnerabilities, just took down one of my sites today.

  34. Going back and forth with “gray ayer” over on the W3T3 forums – He received confirmation that the some ISPs are going in and auto updating the plugin. This absolutely infuriating me, as I had a customized and perfected version of W3 Total Cache working. 0.9.2.9 has tore up some sites since being released and I did not want to upgrade until those issues were resolved. The ISPs’s are quoting an article that clearly states that if you use a third party comments app such as Disqus, you are not effected, yet the sites were all upgraded without no notification to the site owner, no emails, nothing. Not even a backup of the original settings.

    This auto upgrade completely screwed up four of my websites and left them in the default W3TC settings. This is not “normal” host behavior.

    BlueHost has been confirmed, I am waiting on a Justhost confirmation, but most likely will not even get a reply.

  37. I could be wrong, but if you are an admin or a superadmin and login, click on a budypress page, say Groups or Members and are using the bp-registration-options plugin to not show anyone the later pages unless logged in, they get cached and showed to anyone not logged in. The only way is to empty cache and not to click on them while logged in which is stupid. Either bp-registration-options needs to be updated or something wrong with WP super cache plugin, or even Buddypress maybe at fault, I’d like to know if someone else has that problem and the remedy. I WSC set to not cache pages for known users and not to cache these bp pages, still caches them and shows them to anyone. You can test to see if I am correct on blognalists.com

  38. I figured it out. It turns out that for the pages …./groups and …./members if you don’t want them to be cached, UNLIKE the author’s advice which is “Add here strings (not a filename) that forces a page not to be cached.
    For example, if your URLs include year and you dont want to cache last
    year posts, it’s enough to specify the year, i.e. ’/2004/’. WP-Cache
    will search if that string is part of the URI and if so, it will not
    cache that page.”,

    DO NOT INCLUDE THE FORWARD SLASHES. So, just groups instead of /groups or groups/ or /groups/ and members instead of /members or members/ or /members/ etc.

    When it said /2004/ I assumed to add /members/ and /groups/ etc. The help blob should be updated to show so for auther plugins and for clarity!

  40. I also use wp super cache plugin. And I prefer to use to use the old version than the latest version. Indeed, not all hosting activate apache module is needed wp super cache, so that when the switch in the mode of ‘mod_rewrite’ super cache is not working as it should, it would only rely on mode PHP cache 🙂

  41. Pingback: W3 Total Cache and WP Super Cache Vulnerability Being Targeted in the Wild | Sucuri Blog

Comments are closed.

Related Categories
You May Also Like