CVSS – Is Version 3 All Bad?

Over the past months, we’ve been blogging in our CVSSv3 series about various concerns and problems with CVSSv3 either introduced in CVSSv3 or that existed since CVSSv2. We have also discussed the shift and increased severity ratings, which we have seen with the scoring system itself.

To be fair, it is important to know that CVSSv3 is not all bad news. In this blog post, we are, therefore, going to discuss a few aspects of CVSSv3 that we do like and consider great improvements over CVSSv2.


Goodbye ‘Complete’ Impact Score; Hello ‘High’

A big problem with CVSSv2 is how its impact metrics – Confidentiality (C), Integrity (I), and Availability (A) – have the three possible values named:

  • None (N)
  • Partial (P)
  • Complete (C)

These values reflect the impact on the system itself. Due to their naming, in order for a vulnerability to e.g. be considered as having a ‘Complete (C)’ impact for any of the three impact metrics, the impact needs to be system-wide. Similarly, ‘None (N)’ means no impact at all. This results in ‘Partial (P)’ ultimately covering a very wide range from “almost no impact” to “almost a complete impact”. In reality, using this structure results in too many vulnerabilities scoring ‘Partial (P)’ even if their impacts were quite severe or insignificant. Basically, very little granularity is provided.

While CVSSv3 still struggles when dealing with remote vulnerabilities with insignificant impacts, as detailed in our previous blog post, CVSSv3 has, fortunately, addressed the challenge with high risk issues.

Rather than representing the overall percentage (proportion) of the systems impacted by an attack, the new metric values reflect the overall degree of impact caused by an attack.

CVSSv3 now provides impact metric values of:

  • None (N)
  • Low (L)
  • High (H)

A score of ‘High (H)’ now not only covers an impact that is considered “complete”, but anything with a significant impact. As an example, consider the following scores for a vulnerability that allows a local user to disclose an administrative user’s password on the system.

In CVSSv2, the correct score for ‘Confidentiality (C)’ would be ‘Partial (P)’, as the immediate impact of the vulnerability does not allow disclosing all information on the system, but rather just the password. In CVSSv3, the impact to ‘Confidentiality (C)’ is now ‘High (H)’ and much better reflects the real-world potential impact.

CVSSv2 = AV:L/AC:L/Au:N/C:P/I:N/A:N = 2.1 (Low)

CVSSv3 =AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N = 5.5 (Medium)

Actually, the CVSSv3 score above is not quite right, because this example nicely leads us to another improvement to the handling of impacts…

Scoring of Immediate Follow-up Impacts

In the example given above, the impact metrics as mentioned in CVSSv2 would be: C:P/I:N/A:N i.e. partial impact to the confidentiality, but otherwise no other impacts. The reason for this is that CVSSv2 specifies that only the immediate impact should be scored, which in this case is the disclosure of the administrative user’s password.

Does that properly reflect the real threat?

No, it does not. If a local user can disclose the administrative user’s password, that local user can immediately use that exact password to elevate privileges to administrator on the system. This is not captured by CVSSv2.

The great news is that CVSSv3 does capture it properly!

According to the CVSSv3 guidelines, not only the immediate impact, but anything that can be “predictably associated with a successful attack” – without it being too far-fetched – should also be reflected by the impact metrics.

“That is, analysts should constrain impacts to a reasonable, final outcome which they are confident an attacker is able to achieve.”

In our example, the impact metrics are, therefore, scored as: C:H/I:H/A:H, making the full CVSSv3 vector string and score the following:

CVSSv3 = AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H = 7.8 (High)

While one could argue that 7.8 seems quite high for a local privilege escalation attack when comparing to some scores for remote issues, it does certainly better capture the real-world impact to the system than the CVSSv2 score of 2.1. It does not downplay the severity with the potential result of causing organizations relying on the CVSS scores to improperly prioritize the issue.

User Interaction (UI) and Privileges Required (PR)

CVSSv3 also introduces a few new metrics. Two of these worth highlighting are ‘User Interaction (UI)’ and ‘Privileges Required (PR)’. Both have added much needed granularity when scoring vulnerabilities and also makes the vector strings more useful when looking for a quick overview of a vulnerability.

The ‘User Interaction (UI)’ metric is pretty self-explanatory and specifies whether or not exploitation of a given vulnerability relies on user interaction (think of a user clicking a link!). If it does, the severity of the issue is slightly reduced, which makes sense.

The ‘Privileges Required (PR)’ metric is used to specify the permission level required for the attacker in order to exploit the vulnerability. The value can be either ‘None (N)’, ‘Low (L)’, or ‘High (H)’. The higher the permissions required to exploit a given vulnerability; the lesser the severity. We believe that this nicely reflects the real-world view of a vulnerability’s true potential severity.

We welcome both of these new metrics in CVSSv3 and believe they are an improvement even if other bad decisions were made elsewhere to reduce granularity. Yes, we are trying to stay positive, but couldn’t help ourselves! =)


We already discussed the newly introduced ‘Scope (S)’ metric in a previous blog post at length. As we mentioned in that blog post, the ‘Scope (S)’ metric introduces some problems related to how the guidelines specify its use, but it actually does also provide benefits over CVSSv2 when it comes to scoring certain types of vulnerabilities related to sandboxes and virtualized environments.

Scoring vulnerabilities with CVSSv2 is not really useful when dealing with sandboxes and virtualized environments. Analysts are forced to either ignore such limitations or try to work somewhat around them with pretty special scoring approaches. By adding the ‘Scope (S)’ metric, CVSSv3 now makes it possible to better reflect when a change in authorization scope occurs and score such cases properly. Even though there are still some minor problems when using it to score sandbox issues, it works quite nicely for virtualized environments, which was also the main focus point when this new metric was introduced.

Our next and final blog post in this series is going to sum up our conclusions on CVSSv3, and attempt to determine if it succeeded in meeting its goal of providing “a robust and useful scoring system for IT vulnerabilities that is fit for the future.