Support » Plugins » W3 Total Cache critical vulnerability disclosed

  • One of the most popular WordPress Plugin called “W3 Total Cache” which is used to Improve site performance and user experience via caching, having potential vulnerability. On Christmas day, someone disclose it on full-disclosure site that how a plugin misconfiguration leads to possible WordPress cms hack.

    The loophole is actually activated on the fact that how W3TC stores the database cache. Jason disclosed that cache data is stored in public accessible directory, from where a malicious attack can can retrieve password hashes and other database information.

    Default location where this plugin stores data is “/wp-content/w3tc/dbcache/” and if directory listing is enabled, attacker can browse and download it.

    He said,”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.”

    Because the plugin is very famous ,so this makes quite easy for hackers to play with WordPress blogs. Author also publish a simple shell script to identify and exploit this bug.

    We would like to recommend webmasters to either upgrade the plugin to new version or deny access to plugin directory by making an extra .htccess in that folder.

Viewing 12 replies - 1 through 12 (of 12 total)
  • does it help to disable the plugin until a fix to this vulnerability becomes available ?

    I read another story about this issue, and the author recommended “deny access to plugin directory by making an extra .htccess in that folder.”

    How would I do that? I can’t disable the plugin on the site where it runs…

    Edit: After a little more research, I found the answer here: article

    It seems the easiest way to protect your sites is by disabling database cache or creating an .htaccess file inside the wp-content/w3tc directory denying direct access there:

    deny from all

    If you are not using Apache, you will need a similar configuration entry to prevent direct access to the w3tc folder.


    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 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 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.


    You wrote:

    “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.”

    So does this mean the next release still hasn’t been released yet?

    Will you be posting here when the next release comes out?

    You’ll see a notification in your dashboard when the next release comes out.

    But I have uninstalled the plugin as soon as I read about the security vulnerabilities. I don’t want to risk attack so won’t reinstall it until the security hole has been fixed.

    I guess I’ll have to check in on your site from time to time then to see when it has been fixed.

    The plugin is 3 years old with millions of downloads and only one vulnerability has been found for those with a specific configuration of their web server AND W3 Total Cache. Uninstallation was not necessary.

    No offence intended Fredrick, I just want to ensure my sites are secure. I am not sure if my web server’s configuration is set in that specific way or not. So best to be safe than sorry, so I uninstalled the plugin until it gets fixed. Once it is fixed I’ll reinstall it.

    It’s been fixed.

    Hey there,

    Per instructions from my provider, I installed .9.2.8 this past weekend on a WP install running 3.5.1.

    Two days later, I received notification from Google Webmaster my site had been hacked. Further scanning and then research revealed I had been hit by the same hack as described here

    Just an FYI you have another vulnerability on your hands.


    You need to be sure that your site was actually fully “cleaned” up meaning that the party that hacked wasn’t still able to access your site regardless of the software run there. The vector that was identified literally is not possible to compromise in the same way, it’s been vetted by WordPress core developers and industry leading security analysts (the same guy that found the issue as well).

    So again, have a company like have a look at your server for back doors, update your database and site credentials, add basic authentication to WP Admin etc.

    My apologies for the very late reply, but wanted to follow up:

    The site WAS fully cleaned by myself and double checked by my host provider (Dreamhost). It was also checked against to be doubly sure, which I do on a regular basis (once a week and whenever I install a new plugin). I was assured by both AND Dreamhost my site was clean and yet, after installing the plugin after you patched it, I was hacked.

    Anamoly? Perhaps. But there you go.

Viewing 12 replies - 1 through 12 (of 12 total)
  • The topic ‘W3 Total Cache critical vulnerability disclosed’ is closed to new replies.