WP Caching plugin vulnerability debrief

Now that both WP Super Cache and W3 Total Cache developers have released a new version of their respective plugins (upgrade first, continue reading after) it seems time for a small “post mortem“.

The problem was in the interpretation of dynamic snippets, that are contained inside a number of specific HTML-comment tags. These snippets allow both plugins (and their predecessor WP Cache) to cache pages while keeping a limited amount of dynamic, PHP-generated content in them that can be executed on the fly. Think ESI in e.g. Varnish.

The vulnerability, which was originally discovered by kisscsaby and reported 3 weeks ago on the wordpress.org plugins support forum, had multiple causes:

  1. Unlike ESI’s, dynamic snippets can not only be includes (mclude) but also PHP-code (mfunc). Whereas one could consider includes of known files more or less safe, inclusion of PHP-code introduces a risk.
  2. As WP Super Cache & W3 Total Cache keep entire pages in cache and as pages can contain comments, that user generated content is parsed for dynamic snippets as well.
  3. WordPress core by default only allows a limited set of HTML in comments (“a blockquote code em strong ul ol li”), but it also leaves HTML comments in place.

As a result, blogs with WP Super Cache (before version 1.3) and W3 Total Cache (before version 0.9.2.9) were at risk of PHP code injection. Blog comments could contain dynamic snippets (in HTML-comments) and WordPress core did not them filter out. Upon a such a malicious comment having been submitted, a new cached version of the page was created that included the injected PHP-code. Upon the first request of the cached page, that code was successfully executed.

I stumbled on the vulnerability report about a week and a half ago, while researching why dynamic snippets weren’t executing when Autoptimize was active (simple really, Autoptimize by default removes HTML comments, the upcoming 1.6.3 will leave mfunc/mclude in place). As this seemed like a pretty severe security hole and as there was no feedback from developers in the support thread, I created a small “stopgap plugin” to mitigate the threat on April 10th, mailed security@wordpress.org and plugins@wordpress.org and requested WP Safer Cache being published on wordpress.org on the 11th. A couple of hours later WP Super Cache’s Donncha O Caoimh contacted me and the same day he released a version (1.3) that fixed this vulnerability by parsing out potential exploits from comments as they are posted and as they are rendered. On April 12th W3 Total Cache’s Frederick Townes confirmed they were working on a fix. Version 0.9.2.9 got released on April 17th, disabling dynamic snippets by default and when these are enabled, they require a secret alphanumeric key to be included in the snippet which is checked against one that is defined in wp-config.php.

Conclusions; The fact that this didn’t generate any fuss (as opposed to W3 Total Cache’s widely published information disclosure vulnerability in December 2012) is surprising. PHP Code injection clearly is a more severe security risk that must have been there for a long time already. The fact that this only got discovered recently is baffling. And why WordPress core doesn’t filter out HTML-comments from submitted blog comments, others seem to understand, but to me that remains the biggest mystery of all.

24 thoughts on “WP Caching plugin vulnerability debrief

  1. Arick

    I was using one of the caching plugins above and didn’t aware of the security breach.
    PHP Injection is the worst case for me.

    Luckily I found your plugins in WordPress plugins repository. I’m rarely visit plugins repository, Maybe once a month. Upgrading a plugin was not easy as easy job for me. I have to make sure everything work just fine or better than earlier version. I modified lots of WordPress core and using custom build for my blog. While updated plugin may work better for blogger, it may do the opposite for me. Whenever new version pop up, I have to modify many things to make it work flawlessly. If I use your plugins, there would be no need to modify many aspect of the updated plugin. Luckily, I have updated the plugin few days ago. It was hard job for me. If I use your plugin, there would be no need to update the plugin (but I love updated plugins).

    Reply
  2. Pingback: Daily Mozy - Update WP Super Cache and W3TC Immediately – Remote Code Execution Vulnerability Disclosed

  3. Pingback: Security Alert: WP Super Cache and W3 Total Cache - WP Daily

  4. Pingback: Update WP Super Cache and W3TC Immediately – Remote Code Execution Vulnerabi… | Bill Drew the Librarian

  5. Pingback: WP Super Cache 1.3.2 - Holy Shmoly!

  6. Pingback: IT Secure Site » Blog Archive » WordPress cache plugins enabled remote PHP execution

  7. Pingback: WordPress缓存插件可远程执行PHP代码- FreebuF.COM

  8. Pingback: WordPress缓存插件可远程执行PHP代码 | J0s1ph's Blog

  9. Pingback: WordPress 缓存插件可远程执行 PHP 代码

  10. Pingback: WordPress Caching Plugins Vulnerable to Remote Code Execution

  11. Pingback: Updates Fix PHP-Injection Flaw in Popular WordPress Plugins | infosec360

  12. Andrew

    Is this exploit limited to WP total cache and WP super cache only? What about hypercache?

    I only use wp total cache as a plugin to implement CDN on my site, should i be worried about this hack despite having caching disabled in W3TC?

    Thanks for this great post though.

    Reply
    1. frank Post author

      Not 100% sure, but I don’t think hypercache does dynamic snippets and I indeed think that if you don’t use W3TC’s caching, you’re in the clear. But I would upgrade to the latest version nevertheless.

      Reply
  13. Arick

    It may have no relation with the article but I see this blog is member of adfreeblog.org

    I visited a link available in right sidebar and read the whole concept. I have to admit the idea was good. I’m thinking to implement it on my sites (in future, not now).

    However, I need to pay the server (all my blog is hosted on my private server), so few blogs (3 or 4 blogs) will have ads and the others will remain ads free. I know it sound weird but that is what I can do to help blogs Ads Free.

    I want to write and ask the owner of adfreeblog.org but unable to get the comment form (maybe it only accept email).

    Arick.

    Reply
    1. frank Post author

      adfreeblog as an idea stil lives, but the organization (or the people who initiated it) doesn’t seem to be there any more. I guess you can just put the banner up on those blog that don’t have ads?

      Reply
      1. Arick

        Thanks for clearing my doubt. I’ll place the banner in my blog which has no ads. I was talking with my friends in FB and they seems really interested to be “adsfree” blog (most of them is in blogspot and only few has TLD).
        AdsFreeBlog is a choice for everyone. I wish AdsFreeblog can be a new trend in future.

  14. Pingback: Опасные уязвимости во FreeBSD, ядре Linux, tinc, memcached, Joomla и плагинах кэширования для WordPress | AllUNIX.ru — Всероссийский портал о UNIX-системах

  15. Pingback: ..:.:.:: Ufa FreeBSD News][ ::.:.:..

  16. Pingback: Updates Fix PHP-Injection Flaw in Popular WordPress Plugins | Threatpost

  17. Pingback: Running WordPress... Y U no Patch??

  18. Pingback: W3 Total Cache And WP Super Cache Users Should Update To Avoid Remote Code Execution Vulnerability | @nexcess

  19. Pingback: Antonio Herraiz Sousa | PHP shell exploiting mfunc vulnerability in WordPress

  20. Pingback: Dangerous vulnerability in caching plugins for WordPress | MALWARELIST - Your Information Security Source

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>