Compute a CVSS v3.1 base score from the eight base metrics, with the impact and exploitability sub-scores, vector string and severity rating.
This is the published CVSS v3.1 base-metric arithmetic, not an approximation. The three impact metrics combine multiplicatively into the ISS so that a second High impact adds less than the first; the four exploitability metrics multiply into a 0–3.9 sub-score; and Privileges Required is read from the higher of two weight columns when Scope changes, because escaping the vulnerable component is worth more to an attacker. The final value uses the specification's integer Roundup(), which is why 8.75 becomes 8.8 and never 8.7. The base score is the number that drives your patch SLA, your vendor conversations and half your audit evidence — and reproducing it exactly is the only way to tell whether a vendor advisory has scored its own bug honestly.
CVSS v3 Score
ISS = 1 − (1 − C)(1 − I)(1 − A). Impact = 6.42 × ISS when scope is unchanged, and 7.52 × (ISS − 0.029) − 3.25 × (ISS − 0.02)^15 when scope changes. Exploitability = 8.22 × AV × AC × PR × UI. Base = 0 if Impact ≤ 0, else roundup(min(Impact + Exploitability, 10)), or roundup(min(1.08 × (Impact + Exploitability), 10)) when scope changes.
Official Roundup() function
Roundup(x) = int(x × 100000); if that integer is divisible by 10000 it is exact, so return it ÷ 100000, otherwise return (floor(int ÷ 10000) + 1) ÷ 10.
ISS = 1 − (1 − C)(1 − I)(1 − A). Impact = 6.42 × ISS when scope is unchanged, and 7.52 × (ISS − 0.029) − 3.25 × (ISS − 0.02)^15 when scope changes. Exploitability = 8.22 × AV × AC × PR × UI. Base = 0 if Impact ≤ 0, else roundup(min(Impact + Exploitability, 10)), or roundup(min(1.08 × (Impact + Exploitability), 10)) when scope changes. This is the published CVSS v3.1 base-metric arithmetic, not an approximation. The three impact metrics combine multiplicatively into the ISS so that a second High impact adds less than the first; the four exploitability metrics multiply into a 0–3.9 sub-score; and Privileges Required is read from the higher of two weight columns when Scope changes, because escaping the vulnerable component is worth more to an attacker. The final value uses the specification's integer Roundup(), which is why 8.75 becomes 8.8 and never 8.7.
The base score is the number that drives your patch SLA, your vendor conversations and half your audit evidence — and reproducing it exactly is the only way to tell whether a vendor advisory has scored its own bug honestly.
This calculator takes 8 inputs: Attack Vector (AV), Attack Complexity (AC), Privileges Required (PR), User Interaction (UI), Scope (S), Confidentiality Impact (C), Integrity Impact (I), Availability Impact (A). The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
Almost always because of Scope or Privileges Required. Vendors frequently score a bug as Scope:Unchanged when a sandbox escape or hypervisor break makes it Changed, and the 1.08 multiplier plus the higher PR weights can move the score by more than a point. Compare vector strings, not scores.
No. The base score deliberately excludes your environment and the real world, so a 9.8 in a component you do not expose is less urgent than a 7.5 that is listed in CISA KEV with a high EPSS score. Use the base score for severity and the patch priority calculator for order of work.
They are separate metric groups that modify the base score for exploit maturity, remediation level and your own C/I/A requirements. This calculator implements the base group only, which is what CVE records and vendor advisories publish.