We recently have been looking to see if there is additional data that we can add to our service that would be useful to our customers. So far that has resulted in us adding data on false reports of vulnerabilities to the results shown on the admin page of the service’s companion plugin. Another item that we have taken a look and decided not implement, but we thought was worth publicly discussing, is including vulnerability scores based on the popular common vulnerability scoring system (CVSS).

The CVSS is describe as “an open framework for communicating the characteristics and severity of software vulnerabilities”. The scoring produces three scores, but for the purposes we will only discuss the Base score, which is often the only score provided. Scores range from 0.0 to 10.0, with 10.0 being the most severe. There are also textual score based on the numerical scores, which ranges from none to critical. In addition to there being three different the scores,  there are now three versions of the scoring system.

One proponent of the CVSS is Wordfence and they promoted it with the following:

Wordfence has now standardized on using the CVSS 3.0 vulnerability scoring systemwhich we have included in this post. Going forward we will include the CVSS score of every vulnerability in the subject of our blog posts and in an email alert we send to our community. This gives our community an immediate indication at a glance of the severity of a vulnerability. It also provides an objective methodology of scoring vulnerabilities that is not subject to opinion or bias.

Considering their track record and what they wrote, it pointed to the score being of less real value and more of giving the appearance of something useful, while being of little use. From our experience minor differences can make a big difference in the impact of a vulnerability, so subjectivity and opinion could be important in making a score useful, but that wouldn’t have the same optics.

Giving more weight to the idea that the score being more about the appearance of usefulness, than actual usefulness, consider this report of a vulnerability in the plugin Robo Gallery. The vulnerability was given a CVSS score of 8.9 by the reporter, which would seem to be, if anything, a little low for a remote code execution vulnerability. So why did we suggest the score wasn’t very useful? It has do with the fact that vulnerability didn’t actually exist.

Looking at scores that Wordfence has provided for various vulnerabilities they have disclosed, shows the scores for WordPress plugins seem much to high with the scoring system. Take a reflected cross-site scripting (XSS) vulnerability in their own plugin, which they gave a score of 6.1, or medium. We don’t see any widespread targeting of this type of vulnerability, which probably is due in part to the fact that all of the major web browsers other than Firefox have long had XSS filtering that would prevent exploit attempts from being successful unless the hacker could figure a way around them, so an accurate severity score seems like it should be much lower.

Another example along those lines was a vulnerability in that would allow a logged in user to view the settings of a plugin, which it looks like would in most cases be publicly displayed on the website already. Since most WordPress websites don’t allow untrusted individuals to have account, the ability to exploit this would be limited. Even if they could, since the data looks like it would normally be public, the value of the exploits seems very limited. Wordfence gave it a score of 5.3 or medium.

The final example shows the limitation of a non-subjective approach. They gave a score of 9.6 or critical to a remote code execution vulnerability. The big problem with that score is that it only exploitable if the plugin is being used on a multisite installation and considering the vast majority of WordPress installation are not multisite installations the score would be a 0 for them. You would also need to be logged in to exploit this, which further limits exploitation.

What looks to be a major problem with providing a score that is actually accurate representation of the severity of the vulnerability when using CVSS scores for WordPress plugin is that one of the metric will always be the most severe for them, which in our view distorts the score. In version 2 of the CVSS the metric is referred to as access vector and in version 3 as attack vector. Both refer to what access is required to exploit the vulnerability. In both scoring systems a WordPress plugin vulnerability would always be a Network vector. That has a significant impact on the overall score. In version 2 if a vulnerability had the most severe rating for everything else, but had the lowest for access vector the score would 7.2 versus 10.0 if it had the highest. In version 3, it not quite as significant a change with a top score of 7.6 for the lowest attack vector rating versus 10.0 if it it had the highest. Even then about a quarter of the score is locked in no matter the particulars of the vulnerability.

If you have ideas for further improvements to the data we present in the plugins or any similar suggestions please get in touch with us.