Merry Christmas!! Well, Christmas has passed, but on Christmas Eve WordPress users received an early Christmas gift. There is a confirmed security issue with the W3 Total Cache WordPress Plugin that can expose your WordPress website to crackers. This issue is a little more serious than most that I’ve seen because it exposes your user passwords in a cache file. First, let’s look at why you might want to use W3 Total Cache and then we’ll examine the vulnerability.

Featured Plugin - WordPress Q&A Site Plugin
What Does It Do?
W3 Total Cache can help you serve your web pages faster by performing several actions to make the pages serve and load faster.
Cache Pages And Database Queries
Every time someone visits a page on your WordPress website, in order to send the information to their browser, your server must visit your MySQL database a number of times to get all the information it needs to put the page together. It must also consult the code on your website, consider the CSS, and a number of other operations. Each visit to the database, the CSS, and the code takes a certain amount of time to accomplish – even though that time may be very small. Each operation adds time before the page can be served to the end user.
W3 Total Cache goes ahead and constructs each page ahead of time and instead of revisiting all the different places and assembling the page as it’s needed, it only has to serve the page that it has already prepared. Additionally, as things do change on your website, it will prepare a new version of the page to serve. This not only takes a load off of your server, but also is supposed to load your website for your visitor much faster.
Minify Javascript and CSS

Have you ever dug into the CSS of your WordPress theme? Is it all in one file? Or is it in multiple files? I was shocked to learn that some themes have as many as 10 separate CSS files. And a lot of the information is duplicated. Add a couple of plugins that have their own CSS and Javascript and pretty soon you’ve got a mess similar to my woodworking shop when I’m in the middle of a project – stuff lying everywhere – it takes me a while to find what I need sometimes even if I know where it is. Similarly, pulling all this information from multiple places adds to the load time of your website.
W3 Total Cache performs some magic and puts all your CSS into a single, compact, and efficient file that is quickly and easily searched when the information is needed. Of course, don’t fret, when you go to edit your CSS or your Javascript files, the original multiple files still exist and those are the ones you will modify. When you finish modifying them, W3 Total Cache will just package them into a single file all over again – all the while preserving the original multiple files.
Streamline Your Visitors Browser Cache
Your visitors web browsers don’t instinctively know what items from your website can be cached on the visitors computer and which should not. Additionally, the browser doesn’t know how long to cache information from your website. UNLESS your website gives it the information necessary to know what to cache and for how long.
W3 Total Cache makes sure that this information is prepared and sent to your visitors web browser so that it knows what to cache and how long to cache it. That makes sure that their local cache is as effective and efficient as possible. In theory, that should make your website load faster on their computer.
Featured Plugin - WordPress Newsletter Plugin
What Is The Vulnerability?
You may be saying to yourself, “Well, if it’s that good, where is the security issue?” Sounds like it’s just fantastic doesn’t it. What could be wrong?
Basically, all this caching of your website files will store some information that you don’t want the world to know – primarily the encrypted password of your user account. Normally, just storing this information on your hosting account would not be a problem, but there are two potential situations that may expose your sensitive data to a cracker.
Issue #1
By default W3 Total Cache stores the cache files in the /wp-content/w3tc/dbcache/ directory and if you have directory listing enabled on your server, anyone can do a simple Google search on inurl:wp-content/w3tc and find websites that are potential targets for this security issue. Once they find a WordPress website that is exposing this data, they can simply download the cache files to their computer.
Once they’ve downloaded your cache files, a cracker can browser your database cache files and locate your database keys (such as your password hashes). What damage could be done by a cracker if they have your usernames and can decode your passwords? This could get bad couldn’t it?
Issue #2
Even if directory browsing is not enabled, someone aware of this security hole can directly download your whole database cache and then search through it just as noted above. There is a screencast of how Jason, the person who reported this to Full Disclosure, can find out your usernames and password hashes. Simply visit the screen cast at http://git.zx2c4.com/w3-total-fail/plain/screencast.ogv.
Want to poke around and see if you can discover these values on your own WordPress website? Then, use the code that he posted at http://git.zx2c4.com/w3-total-fail/tree/w3-total-fail.sh. I now WPMU.org take any responsibility for how you use his code or for any damage that may occur from using his code. I only note it here in case you want to know more.
There is more information on the Full Disclosure list from the person that discovered this vulnerability.
What Can I Do?
There have been many suggested fixes to plug this security hole, but most have since been proven to be of little value. I’ve seen an .htaccess trick to block access, but most of these files must be publicly accessible to be served to your visitors web browsers, so you can’t completely block access to them.
I apologize if this appears to be oversimplified for all the data that I’ve presented, but the best fix is to “UPDATE IMMEDIATELY”. The developer just released a new version on December 29, 2012 that is supposed to close up this security hole. The revision that fixes this is Version 0.9.2.5. According to the plugin author this version:
“Fixed security issue that can occur if using database caching to disk. If using database caching to disk with a web server with directory listing or web accessible wp-content/w3tc/dbcache/* directories. This patch works for all hosting environments / types where PHP is properly configured, i.e. .htaccess modifications (or other web server configuration changes) are not necessary to ensure proper security. Empty the database cache after performing the update if you use database caching to disk.”
While you are logged in to your WordPress Admin Dashboard, go ahead and update the WordPress core if you’ve not done so already. Then, update your themes if they are not up to date. Finally, update any plugins that are not up to date. Once everything is up to date, commit to yourself that you will keep it up to date in the future. So many WordPress exploits are the result of not keeping things up to date. There are tools that can help with this, but ultimately the responsibility falls to you.
Also, ask your hosting provider to turn off directory listing. If you are on shared hosting, you will probably not be able to get this done unless they have it turned off already. If your host will not turn directory listing you have a couple of options – stick with your current host and hope it is never an issue (yeah right) or change to a host that has directory listing turned off or will turn it off for you.
Featured Plugin - WordPress Google Maps Plugin
This is a perfect example of why using WordPress is not a “set it and forget it” method of building websites – either for yourself or for clients. When I first started working with local clients, they would almost always tell me that they didn’t really need monthly “maintenance” for their websites. So, I changed my language in explaining that service. I now explain to them that the core code for their website is constantly being improved and therefore regular periodic updates are necessary to maintain the security and integrity of their websites. I’ve found that a little education of WHY they need to hire me for the monthly work is usually sufficient to help them understand and make the decision to hire me.
Once you’ve updated the plugin to the latest version, be sure to visit my colleague’s article 2 Plugins To Put Your Site In The Fast Lane to learn some methods to speed up your WordPress website. Also, be sure to leave a comment here about your experiences with W3 Total Cache.
Photo Credits:
patrickjona via photopin cc
voyageAnatolia.blogspot.com via photopin cc
Tambako the Jaguar via photopin cc

Many thanks for the thorough and helpful post. I just updated….
I’m taking to heart the advice at the end: “Once everything is up to date, commit to yourself that you will keep it up to date in the future… This is a perfect example of why using WordPress is not a ‘set it and forget it’ method of building websites.”
Thanks for commenting Hal.
Congratulations for updating everything. Go buy yourself a coffee – or a strong drink. Also, by committing to keep things up to date, you are in a minority I’m sure. It can get tedious sometimes, but just like backing up our hard drive on our local computer we don’t really notice how important it is until we need it.
Keep up the great work and stop back by to read more tomorrow.
Great post. I also saw this and thought I might share…Frederick is the plugin’s dev and top-notch guy.
via: http://bit.ly/W7Wiiv
Re: WordPress Remote Exploit – W3 Total Cache
From: Frederick Townes
Date: Fri, 28 Dec 2012 11:42:53 -0600
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 0.9.2.4 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.
Thanks for sharing this Rone. I had seen this memo from the developer and when I went back to find it to post in the article, I couldn’t find it again. I guess that’s because I get several thousand emails a day, but I’m glad you had it handy and could post it here.
No problem. I appreciate the article (which was my first time hearing of this issue) and the response by the developer. Having been a subscriber of WPMU.org and worked with both Frederick and Willie over at W3Edge, I didn’t expect any less from either party. Cheers and Happy New Year! :)
Yes, I had this article almost written on Christmas day, but held it because I had read that he was working on the issue. I figured that if he took the time and effort to comment on Christmas eve, he was probably a “stand up guy” and would fix it pretty quickly. Of course, I had to change my article a little bit once it was completed because that gave me some additional information.
Thanks for article James. It good to have remind to update, specially in relaxed time over the holidays. My server doesn’t allow directory browsing and I wasn’t caching db to disk, but still I am updating plugin right now, what we Aussies would say – Safety first! W3 Total Cache is awesome plugin and thank a lot to Frederick for plugin and quick reaction to fix this issue. Happy Holidays to all!
Thanks for the comments Dean.
Yes, it never hurts to be prepared does it? Safety first! I don’t think that’s just an Aussie term. I heard it almost every day when I worked in a plant environment. Consequently, our accident rate was very, very low. But, as you said, the same should apply to our digital lives as well.
Hope you and everyone else has a super productive and prosperous New Year.
This one caught a few Social Gallery users out too – good example article, I am using it to explain the situation to people who missed the whole W3 total cache thing.
Cheers James – keep up the good (helpful) work!
Goodday @woddysocialgallery.
Thanks for dropping by and commenting and I’m glad you find this helpful. BTW, what’s going on with Social Gallery? Hadn’t heard about any issues, so I’m curious.
Hey James,
Its Woody btw! :p – No problems with the plugin, just that some compression can skew up the javascript :)
I always use W3 total cache for all of my site , but recently it got some problem and i updated new version so it’s ok