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.

26 thoughts on “WP Caching plugin vulnerability debrief”

  1. 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. 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
    • 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
  3. 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
    • 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
      • 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.

        Reply
  4. It has been more than a year since I wrote comments in this blog. I was reading about ‘Bash Bug/Exploitation’ and suddenly remember about ‘PHP Injection’. Bash and PHP Injection are two different things but they do make me worried. I remember writig about my concern in this blog a year ago and that is why I come here after reading about ‘Bash Exploitation’. 🙂
    It is nice to see my older comments in this post. 🙂
    Thanks for your kind reply @Frank.
    Arick

    Reply
    • It has been more than a year after I wrote a comment in this page. Many things has changed. It is nice to see my previous comment in this page. My first post was three years ago. I have learned many things and this site provide me some information I really need. I would like to see my progress in few years later. I hope I could be ‘good’ developer/webmaster in upcoming years.

      Reply

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.