W3 Total Cache Plugin Vulnerability Identified

in Blog

WordPress news websites have been abuzz this week about an identified vulnerability with the W3 Total Cache WordPress Plugin that leaves databases open for exposure. WordPress security analyst Jason A. Donenfeld published a post on the Full Disclosure List on December 24th outlining the issues revolving around the popular plugin, which is used by several high traffic websites including Lockergnome and Mashable.

With nearly 1.4 million downloads and a Star Rating of 4.6 out of 5 Stars, W3 Total Cache is self-billed as a tool that “improves the user experience of your site by improving your server performance, caching every aspect of your site, reducing the download times and providing transparent content delivery network (CDN) integration.”

W3 Total Cache Plugin Logo

Donenfeld’s Full Disclosure Post

However, the post by Donenfeld gives a detailed run-down of security issues, stating that “Unfortunately, it’s frequently incorrectly deployed. When I set it up by going to the WordPress panel and choosing “add plugin” and selecting the plugin from the WordPress Plugin Catalog (or whatever),
it left two avenues of attack open:

1) Directory listings were enabled on the cache directory, which means anyone could easily recursively download all the database cache keys, and extract ones containing sensitive information, such as password hashes. A simple google search of “inurl:wp-content/plugins/w3tc/dbcache” and maybe some other magic reveals this wasn’t just an issue for me. As W3 Total Cache already futzes with the .htaccess file, I see no reason for it not to add “Options -Indexes” to it upon installation. I haven’t read any W3 documentation, so it’s possible this is a known and documented misconfiguration, but maybe not.

2) Even with directory listings off, cache files are by default publicly downloadable, and the key values / file names of the database cache items are easily predictable. Again, it seems odd that “deny from all” isn’t added to the .htaccess file.”

Shell Script

The security expert added a Shell Script to his entry on December 24th that can both identify and exploit the weakness within the W3 Total Cache plugin. The tool that is designed to speed up websites that use the WordPress Content Management System can make your cache files publicly downloadable even when the Directory Listings are turned off, according to Donenfeld, who also provided a justification for going public with his information.

If I had to categorize these holes, I’d say they’re due to ‘misconfiguration,’ but I figure it’s relevant to write in to full-disclosure & webappsec because I’m usually not horrible with configuring things and I made these mistakes several times without realizing. I’m copying the author on this email, as he may want to include a warning message where nieve folks like myself can see it, or document these somewhere if they’re not already, or at least apply the two .htaccess tweaks mentioned above,” Donenfeld wrote.

News Coverage

In spite of the holiday season and well-deserved vacation days being taken by many important individuals in the WordPress community, the news coverage on the W3 Total Cache vulnerability has been heavy. Stories have been published on TechSpot.com, eSecurityPlanet.com, TheRegister.co.uk, and ghacks.net; among others.

The company that is responsible for the W3 Total Cache Plugin is W3 Edge, which has promised to quickly release an update to the software that will plug the vulnerabilities. However, WordPress blog users who incorporate the plugin may want to disable it until a proven fix has been supplied and tested to the public market.

According to Donenfeld, all a potential hacker would need in the meantime to exploit a website using the W3 Total Cache plugin is to know is the key values and file names of the cache items. We will continue to keep our readers updated on this security issue as events develop.

Comments (4)

  • Comment by Michael

    I can’t use it properly. It ruined my blog’s template so I deactivated it.

  • Comment by Michael Scott
    Michael Scott

    Hi Carl,

    Either one of these should help you out with SEO



    Michael Scott

  • Comment by Frederick Townes
    Frederick Townes

    For those of you that use W3 Total Cache to make your sites more performant, thank you. Security issues are always of paramount interest, no matter the scope.

    The root of the possible vulnerability lies in the intersection of two configuration settings, one at the Web Server level and the other at the W3 Total Cache database caching level. You may be vulnerable if the following are true: your server is configured to allow directory listing with enabled public access on W3TC’s database caching directories and also use database caching via the disk caching method. These settings would allow a hacker to break the md5 hashing used for the then publicly accessible cached database objects. The manner, extent and timing of the vulnerability’s report leave much to be desired; nonetheless, the versions have now been patched on wordpress.org. Thanks to those that offered remediation advice. I’m sorry for the delay in turning this around, none of the proposed solutions were satisfactory.

    The hotfix (tested with WordPress version 3.5) will help those who are just now upgrading to or are otherwise getting started with W3 Total Cache. Specifically, the hash logic is improved via wp_hash(), significantly stronger than the previous md5 hashing at the compromise of a bit of speed. I’ve also made sure that a web server’s lack of security around directory listings and the standard file structure of W3TC’s hashing logic are no longer of consequence for those attempting to download them from your server.

    For those who are using database caching to disk already, please be sure to disable directory indexing and deny web access to the “wp-content/w3tc/dbcache/” directory in your web configuration, then empty the database cache for good measure. Or, simply deactivate W3 Total Cache, uninstall it, and re-install it via wordpress.org to have the hotfix applied upon re-activation. Again, empty the database cache for good measure. Your settings will not be lost during this process. If all of this is gibberish to you, then simply disable database caching to disk until the next release or use another method if available. Once again, empty the database cache using the button of the same name available on the database caching settings tab.

    If you’re reading this and have seen a post about the issue that does not have this response on it, please do post this for me. Thanks in advance. Happy Holidays.

  • Comment by Kris

    I knew it! My site was hacked year ago using w3tc exploit. I’ve found custom shell script added to w3tc core files, which was able to take control over wordpress and database.