On Monday we introduced a new feature to the service that lets you know how likely is that a WordPress plugin vulnerability is to be exploited. In explaining why we thought the new feature would be useful we wrote in part:

Something we often see is that really minor vulnerabilities, ones that have almost no chance of someone trying to exploit on a website, are instead presented by security companies and the press as being major concerns.

Fast forward a few days we have a good example of this in action. Two days ago a reflected cross-site scripting (XSS) vulnerability was disclosed in the plugin W3 Total Cache (if you were using our service you would have already been notified if the vulnerability impacted you by now). The plugin has 1+ million active installs according to wordpress.org, making it one of the most popular plugins. The vulnerability has not been fixed yet, meaning that lots of website are vulnerable, but not that vulnerable.

A reflected cross-site scripting (XSS) vulnerability allows code (usually JavaScript code) that has been included in a request to be included in the web page returned for the request. It has the potential to cause a users to take action they did not intend. What we know from our work for this service as well as cleaning up many hacked websites is that this type of vulnerability is not one that there are attempts to exploit on the average website. Two important reasons for that seem to be that it requires interaction with a user, say getting someone to visit a URL you specify and that all of the major web browsers other than Firefox provides XSS filtering that will prevent most attempts to exploit this type of vulnerability from being successful.

You wouldn’t know that if you look at the blog post about this vulnerability from SecuPress (the company behind that also happens to make a plugin that competes with W3 Total Cache). Their post is titled “W3 Total Cache Vulnerable to XSS – High Risk”. Their claim that the vulnerability is High Risk is based on a DREAD severity score, which based on this example, is problematic like the CVSS scoring system we looked at before. In this case it looks like part of the problem is SecuPress is limited security knowledge.

The glaring problem is the exploitability section of their score:

Exploitability – How much work is it to launch the attack?
Hide the link in a bit.ly like service, ask the admin to click. done.
Add an iframe with the forged link as HREF, ask admin to visit the page. done.
The “most difficult” part is finding the admin. But if you target a website, i guess you know who is it, you know the target, you know the admin.
8/10

First there is no mention of getting around web browser’s XSS filtering (in fact there is no mention of this important point anywhere in the post, despite this be well known by security people since if ever tried to test such a vulnerability in one of those web browsers you would run into the filtering), which would be a significant issue. The other problem with this is that hackers almost never target websites, instead most hacking attempts are part of mass hacking attempts. That is also something that people involved in web security should understand since it plays an important role in understanding the threat landscape out there.