take CVE-2016-7872 for example.
in National Vulnerability Database webpage, we can see that the cvss2 and cvss3 score are 9.8 and 10.0 respectively.
but in the redhat security advisory page, they are 6.8 and 8.8.
To my understanding, cvss score are being computed via a fixed set of rules (https:/\www.first.org/cvss/specification-document), why are they differ so much?
Working out the inputs to the calculations is very subjective:
Take the CVSSv2:
RH: AV:N/AC:M/Au:N/C:P/I:P/A:P
NVD: AV:N/AC:L/Au:N/C:C/I:C/A:C
Both agree the Attack Vector is Network, and the Authentication is None. But disagree with everything else.
NVD think the attack difficulty is easy and the impact is complete. RH think the attack difficulty is medium and the impact is partial.
Since the attack doesn't get root, I'm not sure impact can really be complete. But you can see why the values are different.
PS: Although not relevant to this case some of the temporal score for CVSSv2 are particularly weird: Take https://nvd.nist.gov/vuln-metrics/cvss/v2-calculator?name=CVE-2016-7872&vector=(AV:N/AC:L/Au:N/C:C/I:C/A:C) and apply a "Official fix available" and the result drops from 10 to 8.7. It you had a rule that you had to fix everything above a 9 immediately, you'd have to fix it if there wasn't a patch, but not if there was a patch available.
Unfortunately, CVSS ratings are always more individual than desired. See my question CVSS Score Remote or Local Scenario for an example of such a discussion.
I am responsible for the CVSS rating on VulDB.com and we face similar problems like NVD. In some cases the exact details are not known which would lead to partial vectors. And partial vectors can't be used to calculate any scores. In this case we try to complete the scores as good as possible. In case of Internet Explorer we tend to use C:P/I:P/A:P because nowadays the default browser is usually used by standard users and not administrators.
But in some other cases we complete to the possible worst case scenario. For example if a vendor claims there is a buffer overflow but he claims it may only lead to denial of service which would be at least C:N/I:N/A:P. If we doubt the impact we then complete to C:P/I:P/A:P. We always flag the vectors+scores with a confidence level which indicates the accuracy of the rating. Some vendors try to tune their scores. If you take a look at scores by some vendors you will see that they try to avoid some upper thresholds to keep their stats good looking.
Many of our visitors are not happy with the different scores from different sources. This is why we add all available scores (e.g. VulDB, vendor, researcher, NVD) and show them if possible. See ID 95550 for example. If there are big differences in rating we are going to explain them. This makes it possible for users to take the score which covers the individual use-case they have to deal with.
