W3 Total Cache critical Vulnerability disclosed

Viewing 13 replies - 31 through 43 (of 43 total)

  • The fix mentioned above totally fixed my response time issues. I swore it was Cloudflare. Give it a shot.

    I’ve updated to .5 and my website now has severe problems – requests time out or don’t return any database content. W3TC is notifying me of the same errors as @alexwoolfson and @mediaink mentioned:

    “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.”
    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’ve re-created all W3TC config & .htaccess options but still not solved.

    At this point the question is: Frederick Townes is technically capable of programming this plugin, or (i read this in this same forum) the people who created the code of this plugin, have abandoned the project, leaving Frederick Townes with more problems?

    I ask this with the maximun humility possible.

    After replacing W3TC with the modified version of 0.9.2.5 mentioned above (https://www.wmiles.com/2013/01/03/w3tc-cache-preload-for-version-0-9-2-5) my problems get reduced to this error message only:

    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.

    … and the page is finally accessible again!

    I received that same minify re-write error. I think just clearing your cache, and verifying your three htaccess files, you should be good to go.

    If you are using a CDN such as Amazon, you should upload all your files once again, to get the new caching config working. Also try the new “Prime” button in the Page Cache setup. Click “Prime Cache”.

    More testing of all 4 of my websites after installing this new version, the initial first response of each site has dropped from about 8-10 seconds, to about .3 – .5 seconds. Amazing.

    The change of the code posted on (https://www.wmiles.com/2013/01/03/w3tc-cache-preload-for-version-0-9-2-5) fixed my page cache issue and running now at the load before the upgrade. Really appreciate the create the fix and posting it.

    When I try to install the modified version of the plugin by uploading the zip file I get an error:

    The package could not be installed. No valid plugins were found.
    Plugin install failed.

    What I am missing, any pointers are appreciated

    @mediaink You have to unzip the plugin and only upload the folder “w3-total-cache” which resides inside the folder “w3-total-cache.0.9.2.5”.

    I did it the hard way.
    1. Disable W3TC.
    2. Rename the folder in the /plugins directory to wp-total-cacheOLD.
    3. Open the “new” plugin in 7Zip.
    4. Remove the version “0.9.2.5” from the folder name. Save
    5. Remove the version “0.9.2.5” from zip file name. Save
    6. Install the newly renamed plugin using the “upload” feature in WP.
    7. Verify W3TC settings and functionality. (New Prime button)
    8. Delete the wp-total-cacheOLD folder in /plugins.

    @daevid thank you for the pointer. I installed the modified upgrade on 5 different sites, all of them are working fine. I am using Disk Basic page caching on litespeed servers

    @sla NGjI’s
    there seems to be a problem with your post on .htaccess rules. Most of it is in keeping with the similar stuff found on httpd.apache.org but there is a missing character in the part:

    #
    RewriteCond %{ENV:REDIRECT_STATUS} 200
    RewriteRule .* - [L
    #

    I think it should be [L].
    With the [L ? 500 Internal Server Error
    With the [L] ? 200 OK

    #
RewriteCond %{ENV:REDIRECT_STATUS} 200
RewriteRule .* - [L]
#

    @slangji’s
    Also, in the part

    #
# 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]
#

    it seems that including xsd|xsl|xml| in the above directive interferes with Yoast WordPress SEO sitemaps (gives 404)..
    Removing xsd|xsl|xml| and keeping the rest as it is fixes it!

    Yepa! ??

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