Loading CVSS Calculator…
A base score is a severity rating, not a risk assessment. It describes what a flaw would allow if someone attacked it, and it knows nothing about whether you run the affected version, whether the affected thing is reachable from where an attacker sits, or what it would cost you if it fell over. A 9.8 on a service you do not expose is less urgent than a 6.5 on your login page.
How close to the vulnerable thing does the attacker have to be?
AV:P §2.1.1The attacker has to touch the hardware. A cold-boot attack on disk keys or a malicious USB device plugged into the port.
Does anything outside the attacker’s control have to go right?
AC:H §2.1.2Success depends on a condition the attacker does not control: winning a race, learning a sequence number, or getting into the network path between two parties.
What does the attacker need to hold before starting?
PR:H §2.1.3Administrative or equivalent control over the vulnerable component. Worth 0.5 rather than 0.27 once Scope is Changed.
Does a second person have to do something?
UI:R §2.1.4A legitimate user has to take an action first — visit a page, open a file, accept a prompt — before the attack lands.
Does the damage stay inside the thing that is broken?
S:U §2.2Everything affected sits inside the same authorisation authority as the vulnerable component.
How much can the attacker read?
C:N §2.3.1Nothing is disclosed. The attacker learns nothing they could not have read already.
How much can the attacker change?
I:N §2.3.2Nothing can be altered. Whatever the attacker reaches, they cannot write to it.
How much service can the attacker take away?
A:N §2.3.3Availability is untouched. The service keeps answering at its usual speed.
0.0 None
Scope is Unchanged, so the total is Impact plus Exploitability, rounded up.
Paste a vector out of an advisory and the metrics above follow it. The CVSS:3.1 prefix is part of the string and all eight base metrics are mandatory.
1 − (1 − C) × (1 − I) × (1 − A)06.42 × ISS08.22 × AV × AC × PR × UI0.1211Minimum [Impact + Exploitability, 10]0Roundup, to one decimal place0.0Metrics, constants, equations and the Roundup function follow the CVSS v3.1 Specification Document (revision 1) published by FIRST: equations in §7.1, constants in Table 16, severity bands in Table 14 and the integer-arithmetic Roundup in Appendix A. Every worked example in the companion CVSS v3.1 Examples document is checked against this implementation in its test suite. Only the base metric group is here — Temporal and Environmental metrics describe a moment and an estate rather than a vulnerability.
The base score answers one question: if somebody attacked this flaw, how bad would that be, given only the properties of the flaw itself? It is deliberately blind to everything about you. It does not know whether you run the affected version, whether the affected component is reachable from where an attacker sits, whether a web application firewall stands in front of it, or what the thing would cost you if it stopped. A 9.8 in a library you ship but never call is less pressing than a 6.5 on your login page, and no amount of staring at the two numbers will tell you that.
This is why a queue sorted purely by base score is a queue sorted by somebody else’s guess about your estate. The score is a good first pass at triage and a poor final answer, and the standard says as much by providing Temporal and Environmental metric groups on top of it — the parts that ask what exploit code exists today and how much this particular asset matters to you.
Attack Vector, Attack Complexity, Privileges Required and User Interaction describe getting in; Confidentiality, Integrity and Availability describe what is then possible. Scope is the odd one out. It asks whether the damage stays inside the security authority of the broken component or escapes it — a hypervisor guest reaching the host, a sandbox breaking out, a script from one origin acting on another.
Setting Scope to Changed does two things at once. It multiplies the total by 1.08, and it quietly raises what Privileges Required is worth: Low moves from 0.62 to 0.68 and High from 0.27 to 0.5. The reasoning is that if the attack escapes the boundary, whatever privilege the attacker held inside it mattered less than it looked. That interaction is where two people scoring the same advisory most often part company.
CVSS scores are given to one decimal place, always rounded up. Implemented naively as a multiply, a ceiling and a divide, that is wrong often enough to matter, because binary floating point cannot hold most decimal fractions exactly. A sum that should be exactly 4.0 can arrive as 4.000000000000001, and a naive roundup answers 4.1 — a whole severity step in the wrong place at a band boundary.
The specification anticipates this in an appendix and mandates integer arithmetic instead: multiply by 100,000, round to the nearest integer, and do the rounding-up on integers, which have no such problem. This calculator implements that version, and its test suite scores every worked example published alongside the standard and compares each result to the score published with it.
The vector is the whole assessment in one line: the CVSS:3.1 prefix, then each metric as an abbreviation and a value. Paste one from an advisory and the metrics here follow it, which is the fastest way to find out why a rating you disagree with came out where it did — usually a single metric, arguable, worth one conversation rather than an argument about the number.
The prefix is mandatory, so a bare AV:N/AC:L/… is not a valid v3.1 vector even though every tool accepts it. Temporal and Environmental metrics may appear in the same string and are set aside here rather than scored, because they describe a moment in time and one organisation’s estate rather than the vulnerability.
Almost always because a metric was read differently, not because the arithmetic went astray. Compare the vector strings rather than the numbers: one metric value explains the gap, and the usual suspects are Scope, Privileges Required and whether user interaction is genuinely required.
Yes, and it is worth understanding why. If Confidentiality, Integrity and Availability are all None, the impact sub-score is zero and the standard sets the base score to zero however trivially exploitable the flaw is. A flaw that permits nothing is not scored as severe.
The metrics are spelled identically, so a v3.0 vector reads cleanly here, but the two versions do not always produce the same number. The environmental formula changed, and the guidance on several metrics was rewritten, so a score copied between versions should be recalculated rather than assumed.
Only as a starting point. Reachability, whether exploit code is circulating, and what the affected system holds all move an item up or down the queue more than a decimal place does. Score order is a way to break ties, not a plan.