High Risk XSS Vulnerability Discovered in W3 Total Cache Plugin


WP Media is reporting a high risk XSS vulnerability in W3 Total Cache that the company learned about from El Rincón de Zerial’s security blog. The plugin is currently active on more than one million WordPress sites.

This particular vulnerability is found within the plugin’s support form that is embedded in the admin, according to WP Media’s description:

This page can be reach directly using a URL with params, then the params will fill the form.

The params are not escaped when printed on the page, leading to an XSS vulnerability.

Example of XSS URL to be avoided: https://example.com/wp-admin/admin.php?page=w3tc_support&request_type=bug_report&request_id=PAYLOAD

Then replace PAYLOAD with a malicious code.

According to Zerial, in order to exploit the vulnerability, an administrator or user with sufficient permissions must have an active session.

Because the threat is already public with no patch available, the vulnerability’s DREAD score ranks it as High Risk. It’s also easily exploitable and could potentially give an attacker the ability to inject code into the admin area and gain access to security tokens, cookies, and private data.

W3 Total Cache was updated six months ago with a fix for two security issues. The last major update, 0.9.4, was released in 2014. After many users began to wonder if the plugin was abandoned, we spoke with author Frederick Townes in March to learn the status of W3 Total Cache. His said that development and other operations have been ongoing and that his team is working towards leaving officially beta and moving towards a 1.0 release. No major updates have been issued and Townes’ company blog has remained silent.

At this point, the only option users have is to disable the plugin or use an account with author or editor permissions instead of the administrator account. The plugin’s author has been contacted about the vulnerability but there is no security update available via WordPress.org yet.


33 responses to “High Risk XSS Vulnerability Discovered in W3 Total Cache Plugin”

  1. One of the worst maintained, most buggy, and most problematic plugins in the history of WordPress. How W3TC wasn’t banned YEARS ago is one of the true mysteries behind wordpress.org.

    The author, Frederick Townes, doesn’t even seem to grasp basic understanding of PHP or Opcache, which he has refused to support in lieu of (dead) APC for the past several years…

  2. There’s another vulnerability that I haven’t seen reported, and that is the W3 Total Cache credit card vulnerability.

    I purchased W3 2 years ago. Before it was set to renew, I tried to cancel the subscription. Email, support requests, phone calls… crickets.

    My credit card was charged and I successfully disputed the charge. Fast forward to this past Monday. A year later, and they charged my card again!!

    I am mystified as to how this company can even claim to be operational. They do not respond to any contact, and the last post on their blog is from 2014.

  3. I can’t immediately change to other plugin, like WP Super Cache does not handle mobile cache or page with string properly even after setting it up. And other plugin had some other issue. So, right now I needed W3TC to work. I found the fix-w3tc project in github, tested few approach, and after multiple test, shared my best find method here.

  4. For anyone needing time to switch plugins, or anyone who really needs W3TC but needs to make it secure .. this small plugin will stop all access to the W3 total Cache (Version XSS support page,

    just install (preferably as mu-plugin) and you are all done.
    https://github.com/ramonfincken/w3tc_deny_supportpage Instructions are in the README.md file

    W3TC will continue to cache your site, and you will have some “breathing time” to search for an alternative caching plugin.

    Note: I still think it is time that W3Edge releases a fix for this and many other things as well (PHP 7 support for instance).

    • One more bit of advice: The primary purpose of most of these caching plugins for WordPress is to do static page caching. Static page caching is better off done further up the stack. If you can, use something like Nginx or Varnish to handle your page caching, then install a cache purge plugin. This is much more efficient and will give you significantly better performance than any of these basic static page caching plugins ever could. Plus, they’re likely to be less buggy too.

      • You are right but, and it’s a huge but, if people are finding w3tc settings confusing they’ll get lost with Varnish vcl. Besides, Varnish is only really applicable on VPS or dedicated servers where you have control over what you install. For managed or shared hosting the only real solution is a plugin. If your managed hosting is any good though, they’ll do the caching for you.

  5. This part is too vague:

    According to Zerial, in order to exploit the vulnerability, an administrator or user with sufficient permissions must have an active session.

    What does that mean, exactly? The exploit can only work on targeting logged-in admin? The exploit can only work to target other users if there is an admin who has logged in?


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: