Support » Plugin: W3 Total Cache » W3 Total Cache critical Vulnerability disclosed

Viewing 15 replies - 16 through 30 (of 43 total)
  • Plugin Author Frederick Townes


    @gianpaolo.cipicchia, How do you know that this was done through the object cache?

    As for the permissions problems, that’s not unexpected and no one in these forums can even guess why that’s happening without looking at how your particular server is set up.


    For my personal experience, with various hosting, dir and file chmod permission is not problem … W3TC work perfectly with dir 705 and file 604 chmod permission, on various situations.

    @frederick Townes

    1 – What happens if the same malicious script used to exploit db cache is applied to object cache with W3 total Cache

    2 – What happens if the same malicious script used to exploit db cache is applied to advanced cache (disk and enanched mode) with W3 total Cache

    I would agree with most everything here, including best practices for htaccess and so forth, but I take issue with the statement “And just an FYI – if you are using secure passwords then you have nothing to worry about since one-way hashed passwords cannot be cracked.”

    Hashcat with on a workstation with a number of GPU’s, can and will crack wordpress passwords, and people do it all the time. Collisions can and will happen. Especially passwords under 8 characters, will only take about an hour or two on a high end machine with multiple GPU’s doing the cracking. 8 or more characters take a bit longer exponentially for every character over 8 or more in length.

    At a minimum, 14 or more would be more desirable as well as implementing your own form of two factor authentication, or doing as I do and disabling access to wp-login.php and the wp-admin directory via htaccess for anyone other than my own IP.

    Still, its not impossible to break, as the algorithm used to create the hash, can have any number of possibilities for the hash itself and its only a time trade off issue as to when, not if, the password can be broken. Type in any word, and do it continually, the hash changes every time. I use this for myself, when I’ve forgotten the password on systems that don’t have the ability to email passwords or no SMTP setup, and I have to manually edit clients sites that need password resets, I can make my own and just paste in whatever this outputs directly to the database file itself and it works –

    If you are going to block access to indexes, be sure to block access to wp-login.php and wp-admin as well except for your own IP. Its a hassle to update the htaccess file every time your IP changes, but its worth it in my mind. Another alternative, is add htpasswd protection to the wp-admin directory so no one can login, which in some ways, adds a second layer of authentication. Just don’t use the same login name and password for both htpasswd and your wordpress login, but that should go without saying.

    @digip – Yes of course you are correct. Some secure passwords can be cracked in hours, some take months and some take years. I will rephrase my statement – “If you create new secure passwords over 14 characters each month then you have nothing to worry about.”

    @aitpro hope no offense was taken either way. Was not my intention, just wanted to illustrate a point that length with respect to the current password hashing scheme for wordpress alone is not a deterrent for attackers at this point in time and easy access to user names is all they really care about, since they usually just brute force logins once they know the user names and don’t care about needing the hash itself.

    Still, password cracking is a common threat in todays landscape of GPU hardware based password cracking machines, and wordpress passwords in general are quickly broken in hash cracking competitions since the average user only uses a small subset of actual characters for their passwords, often limited to lowercase letters and numbers only and usually no more than 8 characters. Not to mention hash length extension attacks that use probability statistics in reducing the common key space used to only commonly used characters and removing certain letters, special characters, etc, the process of cracking most(but not all) passwords becomes even that much faster when you add additional cracking techniques.

    Not trying to hijack the thread or to cause hysteria, but users should be aware of a number of security practices, not just htaccess control and strong password use, but also monitoring of login attempts, something I hope is someday implemented into wordpress itself to notify admins if a failed password attempt has taken place. There good thing is there are plug-ins to help users in that area to fill the void, including one I’ve written myself, but you don’t need to use mine to be able to log these attempts. There are plenty of other plug-ins that help with that regard and I would suggest every WordPress user consider using some form of login monitoring plug-in that emails the admins of attempts. Just one more layer in a balanced approach to securing your site, and something most users would probably be surprised at how many people are already brute forcing their way into your sites already, directly against the login page of wordpress itself. One of the first things I do when setting up WordPress is install a login alerts plug-in, and change all usernames to use different nicknames for posts and comments, so attackers can’t use default names like admin to login with(which is a topic for a whole other discussion on why you should never setup wordpress with the username admin).

    I deactivated the plugin, upgraded & reactivated the plugin and it is now giving me this error when it didn’t before:

    It appears Minify URL rewriting is not working. If using apache, verify that the server configuration allows .htaccess or if using nginx verify all configuration files are included in the configuration.

    I deactivated and reactivated the plugin again. Deactivated and reactivated the minify part of the plugin. Restarted my Apache server, but the error persists. Looking above at Frederick’s comment, I can see that it’s unlikely that anything can be done without someone knowledgeable about both this plugin and my server looking into it. But if anyone has any suggestions for what kind of permissions setting I’d need to change or look at just for this minify issue (my server does currently allow .htaccess), I’d be grateful for that.

    Also, is it better to leave minify turned off for now?



    I have the same problem, except the issue also impacting disk cache

    “It appears Page Cache URL rewriting is not working. If using apache, verify that the server configuration allows .htaccess or if using nginx verify all configuration files are included in the configuration.”

    Based on the load of the CPU it looks like that the disk cache is not working for me at all. Also reloaded; have still the same problem on the site tried to the the upgrade.

    alexwoolfson wote:

    Is it better to leave minify turned off?


    Turn Minify to manual and take advantage of HTML minification. Minify CSS and JS manual … this work better 😉

    MediaInk wrote:

    Disk cache is not working for me at all. Also reloaded; have still the same problem on the site tried to the the upgrade.

    @mediaink versione release is only simply security fix: all problems discovered on version is the same and unfixed, and also on have some negative unfixed problems … Nothing, for now, was fixed!


    Default password on WordPress since version 3.1 is 12 characters (alphanumeric+simbles)

    Foe my personal opinion best numbers is 15 characters! (alphanumeric+simbles) Strong Password Generator

    For some for some reason of general security is recommended chmod:

    /.htaccess 404
    /favicon.ico 404
    /robots.txt 404
    /index.php 400
    /wp-blog-header.php 400
    /wp-config.php 400
    /xmlrpc.xml 400 if CMS 404 if BLOG
    All others files 604

    / 705
    /wp-admin/ 701 (dir and subdir)
    /wp-content/ 705 (dir and subdir)
    /wp-includes/ 701 (dir and subdir)

    This WP-Trik described take advantage of 404 not found HEADER error reply (same of default /wp-includes/) 😉

    delete /wp-content/index.php
    delete /wp-content/plugins/index.php
    delete /wp-content/themes/index.php
    delete /wp-content/upload/index.php

    Change default wp_ table prefix with wp_????????_ (?=alphanumeric character)


    define('DISALLOW_FILE_MODS',true);//disable dashboard update link

    .htaccess rules:

    IndexIgnore *
    Options -Indexes
    # WP Upgrade Protection
    <Files upgrade.php>
    Order Allow,Deny
    Deny From All
    <Files upgrade-functions.php>
    Order Allow,Deny
    Deny From All
    # WP Install Prevention
    <Files install.php>
    Order Allow,Deny
    Deny From All
    <Files install-helper.php>
    Order Allow,Deny
    Deny From All
    <Files setup-config.php>
    Order Allow,Deny
    Deny From All
    <Files wp-config-sample.php>
    Order Allow,Deny
    Deny From All
    # WP Default Protection
    <Files .htaccess>
    Order Allow,Deny
    Deny From All
    <Files wp-config.php>
    Order Allow,Deny
    Deny From All
    <Files readme.txt>
    Order Allow,Deny
    Deny From All
    <Files readme.html>
    Order Allow,Deny
    Deny From All
    <Files license.txt>
    Order Allow,Deny
    Deny From All
    <Files gpl-2.0.txt>
    Order Allow,Deny
    Deny From All
    RewriteEngine On
    RewriteBase /
    RewriteCond %{ENV:REDIRECT_STATUS} 200
    RewriteRule .* - [L
    RewriteRule ^(.*)$ - [F,L]
    RewriteRule .* - [F,NS,L]
    RewriteCond %{THE_REQUEST} !^[A-Z]{3,9}\ .+\ HTTP/(0\.9|1\.0|1\.1) [NC]
    RewriteRule .* - [F,NS,L]
    # Block the include-only files
    RewriteRule ^wp-admin/includes/ - [F,L]
    RewriteRule !^wp-includes/ - [S=3]
    RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
    RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
    RewriteRule ^wp-includes/theme-compat/ - [F,L]
    # Skip WordPress 404 Error for Static Files
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_FILENAME} \.(php|css|js|htc|html|htm|rtf|rtx|svg|svgz|txt|xsd|xsl|xml|asf|asx|wax|wmv|wmx|avi|bmp|class|divx|doc|docx|eot|exe|gif|gz|gzip|ico|jpg|jpeg|jpe|mdb|mid|midi|mov|qt|mp3|m4a|mp4|m4v|mpeg|mpg|mpe|mpp|otf|odb|odc|odf|odg|odp|ods|odt|ogg|pdf|png|pot|pps|ppt|pptx|ra|ram|svg|svgz|swf|tar|tif|tiff|ttf|ttc|wav|wma|wri|xla|xls|xlsx|xlt|xlw|zip)$ [NC]
    RewriteRule .* - [L]
    # BEGIN WordPress

    Hardening WordPress and Changing File Permissions

    .htaccess headers rules:

    FileETag none
    Header set X-Frame-Options "SAMEORIGIN"
    Header unset Accept-Ranges
    Header unset ETag
    Header unset Pragma
    BrowserMatch MSIE ie
    Header set Imagetoolbar "no" env=ie
    Header set X-Content-Type-Options "nosniff" env=ie
    Header set X-UA-Compatible "IE=edge" env=ie
    Header set X-XSS-Protection "1;mode=block" env=ie
    BrowserMatch SAFARI safari
    Header set X-XSS-Protection "1;mode=block" env=safari
    BrowserMatch CHROME gc
    Header set X-Content-Type-Options "nosniff" env=gc
    BrowserMatch chromeframe gcf
    Header set Imagetoolbar "no" env=gcf
    Header set X-Content-Type-Options "nosniff" env=gcf
    Header set X-UA-Compatible "IE=edge,chrome=1" env=gcf
    Header set X-XSS-Protection "1;mode=block" env=gcf


    Never cache the following pages:
    Cache exception list:
    Non-trailing slash pages:
    Specify page headers:

    W3TC injection protection:

    delete /wp-content/w3tc/index.html
    delete /wp-content/w3tc/index.php

    Put this .htaccess on:


    .htaccess to put it:

    Order Allow,Deny
    Deny From All


    /* Disable Self Pings */
    function no_self_ping(&$links){$home=get_option('home');foreach($links as $l => $link)if(0 === strpos($link,$home))unset($links[$l]);}add_action('pre_ping','no_self_ping');
    /* Remove WordPress version from header */
    /* Hide blog URL from WordPress 'phone home' */
    function disabler_remove_url($default){global $wp_version;return 'WordPress/'.$wp_version;}add_filter('http_headers_useragent','disabler_remove_url');
    // Remove Login Error Message on wp-login.php
    add_filter('login_errors',create_function('$a',"return null;"));
    /* Block Bad Queries*/
    $request_uri_array = apply_filters('request_uri_items', array('eval\(', 'CONCAT', 'UNION\+SELECT', '\(null\)', 'base64_', '\/localhost', '\/pingserver', '\/config\.', '\/wwwroot', '\/makefile', 'crossdomain\.', 'proc\/self\/environ', 'etc\/passwd', '\/https\/', '\/http\/', '\/ftp\/', '\/cgi\/', '\.cgi', '\.exe', '\.sql', '\.ini', '\.dll', '\.asp', '\.jsp', '\/\.bash', '\/\.git', '\/\.svn', '\/\.tar', ' ', '\<', '\>', '\/\=', '\.\.\.', '\+\+\+', '\:\/\/', '\/&&'));
    $query_string_array = apply_filters('query_string_items', array('\?', '\[', '\]', '\.\.\/', '127\.0\.0\.1', 'localhost', 'loopback', '\%0A', '\%0D', '\%22', '\%27', '\%3C', '\%3E', '\%00', '\%2e\%2e', 'union', 'input_file', 'execute', 'mosconfig', 'environ', 'path\=\.', 'mod\=\.'));
    $user_agent_array = apply_filters('user_agent_items', array('binlar', 'casper', 'cmswor', 'diavol', 'dotbot', 'finder', 'flicky', 'jakarta', 'libwww', 'nutch', 'planet', 'purebot', 'pycurl', 'skygrid', 'sucker', 'turnit', 'vikspi', 'zmeu'));
    if (
    	preg_match( '/' . implode( '|', $request_uri_array ) . '/i', $_SERVER['REQUEST_URI'] ) ||
    	preg_match( '/' . implode( '|', $query_string_array ) . '/i', $_SERVER['QUERY_STRING'] )
    	// || preg_match( '/' . implode( '|', $user_agent_array ) . '/i', $_SERVER['HTTP_USER_AGENT'] )
    ) {
    	header('HTTP/1.1 403 Forbidden');
    	header('Status: 403 Forbidden');
    	header('Connection: Close');

    If use FeedBurner (plugins) to replace default WordPress Feed, instruct W3TC to no Minify Feed:


    HTML minify settings:
    Don't minify feeds (checked)

    Instruct W3TC to no Minify Inline Script to maintain default WordPress behavior:


    HTML minify settings:
    Inline JS minification (unchecked)

    Instruct W3TC Don’t cache pages for logged in users to reduce server load:


    Page Cache General:
    Don't cache pages for logged in users (unchecked)

    sLaNGjI’s, thank you for your kind reply.

    My site was working fine before the upgrade using I have also four other sites with and have no problems. My issue is specific to TDF in this tread above had also similar issues with Disk cache.

    I am using Litespeed web server. Any pointers are appreciated.

    @slangji‘s: Thank you very much for your kind reply. I actually was already using manual with the Minify. I agree, it is better.

    Started getting numerous 500 errors on my website tonight. My ISP host looked into it and told me “On further checking, I could see that there were large number of cache files under the plugin w3tc. It was the processing of these files that delayed the execution of the PHP scripts.”

    She “renamed the cache files and this has significantly reduced the server load.”

    I do understand that the changes made to this version of the plugin were very minor. It could all be a coincidence. But reporting here in case it’s helpful to someone.

    In the meantime, I’ve disabled minify in the settings.


    If you Set Minify to Manual, No CPU Load was Increased … 😉 Consider to re-enable it!

    Bye 🙂

    I’ve updated to .5 and now all page caching is non-functional as TDF and Mediaink have reported.

    Timestamps are always fresh and turning on debugging for page caching, it always reports “not cached”.

    I’m using Disk: Basic.

    I’m going to try and revert back to .4 as the load on my server is too high!!!

    Please help.

    I’ve reverted back to .4 and I still get no page caching.

    This is not good!


    For those whose page caching stopped working with the update to .5, someone has posted a fix to this. It is only for Disk: Basic page caching, which is exactly what stopped working for me. I’ve applied the fix and it seems to be working.

    W3TC Cache Preload for Version


Viewing 15 replies - 16 through 30 (of 43 total)
  • The topic ‘W3 Total Cache critical Vulnerability disclosed’ is closed to new replies.