What the base score measures, and what it does not
The CVSS base score describes the qualities of a vulnerability that do not change with time or with where it is deployed. It answers two questions and combines them: how hard is this to exploit, and how bad is it when someone does. The first becomes the exploitability sub-score, the second the impact sub-score, and the base score is essentially their sum, capped at 10 and rounded up.
Three things the base score deliberately excludes are worth stating plainly, because most misuse of CVSS comes from forgetting them. It does not know whether exploit code exists — that is the temporal metric group. It does not know whether the affected system is internet-facing, holds regulated data, or is one of five thousand identical hosts — that is the environmental metric group. And it is not a measure of risk: risk requires a threat and an asset, and the base score has neither. A base score of 9.8 on a lab machine with no data is less urgent than a 5.3 on a payment gateway.
What it does provide is a common vocabulary. When a vendor publishes CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, every reader can reconstruct exactly the same 9.8 and, more usefully, can see why: reachable over the network, no preconditions, no credentials, no user action, total loss of all three security properties. The vector string carries more information than the number, which is why advisories should always publish both.
Version 3.1 is a clarification release rather than a redesign. The equations are identical to v3.0; the change that matters is the Roundup function, which v3.1 defines over integers so that floating-point representation can no longer round a value such as 4.02 down instead of up. Scores computed under v3.0 and v3.1 agree except in a handful of these boundary cases.
How the eight metrics turn into a number
The impact side. Each of confidentiality, integrity and availability carries a weight: High 0.56, Low 0.22, None 0. They combine as ISS = 1 − (1−C)(1−I)(1−A), which is the probabilistic union — a deliberately sub-additive combination, so that a second High impact adds less than the first did. Three High impacts give 1 − 0.44³ = 0.914816 rather than 1.68. Multiply by 6.42 when scope is Unchanged and the impact sub-score maxes out at 5.873.
When scope is Changed the formula becomes 7.52(ISS − 0.029) − 3.25(ISS − 0.02)15. The first term scales up, reflecting that damage has crossed a security boundary; the fifteenth-power term is a shaping correction that only bites near the top of the range, holding the maximum below 6.05. It looks arbitrary because it is a curve fit, not a derivation — CVSS's numbers were chosen to reproduce expert judgement, not deduced from a model.
The exploitability side. 8.22 × AV × AC × PR × UI, a plain product of four weights. Because it is multiplicative, each awkward precondition scales the whole thing down: requiring a low-privileged account multiplies by 0.62/0.85 = 0.73, and requiring user interaction multiplies by the same ratio again. The maximum is 8.22 × 0.85 × 0.77 × 0.85 × 0.85 = 3.887.
Combining. Add the two sub-scores, multiply by 1.08 if scope is Changed, cap at 10, and round up to one decimal. The 1.08 factor and the larger Privileges Required weights are the two other ways Scope: Changed raises a score, on top of the modified impact formula. And one rule overrides everything: if the impact sub-score is zero, the base score is 0.0. A flaw with no confidentiality, integrity or availability consequence scores nothing no matter how trivially it is reached.
Roundup. Multiply by 100,000, round to the nearest integer, and if that integer is not an exact multiple of 10,000, take the next tenth upward. The practical effect is that CVSS never rounds down: 7.42 becomes 7.5, and 7.50 stays 7.5. This is why hand-computed scores that look like they should be 6.0 are published as 6.1.
Worked example: an unauthenticated remote code execution
A web application deserialises untrusted input and allows arbitrary code execution as the service account. It is reachable from the internet, needs no credentials, needs no user to do anything, and works every time. The service account owns all of the application's data, and the process can be crashed at will. Scope is Unchanged because the attacker gains the privileges the vulnerable component already had.
The vector is AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.
- Impact weights. C = I = A = High = 0.56.
- ISS. 1 − (1−0.56)³ = 1 − 0.44³ = 1 − 0.085184 = 0.914816.
- Impact sub-score. 6.42 × 0.914816 = 5.873119.
- Exploitability weights. AV:N = 0.85, AC:L = 0.77, PR:N = 0.85, UI:N = 0.85.
- Exploitability sub-score. 8.22 × 0.85 × 0.77 × 0.85 × 0.85 = 3.887043.
- Sum. 5.873119 + 3.887043 = 9.760161, which is below the cap of 10.
- Roundup. 9.760161 × 100,000 = 976,016; not a multiple of 10,000, so take ⌊976,016 ÷ 10,000⌋ + 1 = 98, giving 9.8.
- Severity. 9.8 is in the 9.0–10.0 band, so Critical.
Now change one judgement. Suppose the flaw needs an ordinary user account. PR becomes Low, weight 0.62, so exploitability falls to 8.22 × 0.85 × 0.77 × 0.62 × 0.85 = 2.835255. The sum is 5.873119 + 2.835255 = 8.708374, and Roundup gives 8.8 — High rather than Critical. One metric moved the score a full point and moved the ticket into a different remediation queue, which is why the Privileges Required decision deserves as much argument as it usually gets.
How to use the score once you have it
Read the vector before the number. Two vulnerabilities can both score 7.5 while behaving completely differently: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N is a remote data leak, and a different combination reaching the same total might be a local denial of service. The number is a sorting key; the vector is the description.
Then layer on what the base score cannot see. Temporal metrics adjust for exploit maturity, remediation availability and report confidence, and they only ever reduce the score. Environmental metrics let you re-rate confidentiality, integrity and availability requirements for your own deployment and adjust the base metrics where your architecture differs from the vendor's assumption — a vulnerability the vendor scored AV:N may be AV:A in your network because the service is not routed. A published base score is a starting point, and treating it as a final priority is the single most common failure of CVSS-driven programmes.
Beware the compression at the top of the scale. Because the maximum impact and exploitability sub-scores are 5.873 and 3.887, a great many genuinely different vulnerabilities land between 9.0 and 10.0 and appear equally urgent. If your queue is full of Criticals, CVSS has stopped discriminating and you need another axis — asset value, internet exposure, exploitability in the wild — to order the work. Quantify the consequence side with the annualised loss expectancy calculator, which multiplies a single-loss figure by an annual rate of occurrence and gives you something denominated in money rather than in points.
Finally, be consistent. CVSS's numbers are stable but its judgements are not: two analysts routinely disagree about Scope and about whether a precondition makes Attack Complexity High. Write down your organisation's conventions for the ambiguous cases, and use the sensitivity table above to see how much a disputed metric actually moves the result. Where the answer is a tenth of a point, stop arguing.
CVSS v3.1 metric weights and severity bands
| Metric | Value | Weight (Scope Unchanged) | Weight (Scope Changed) |
|---|---|---|---|
| Attack Vector | Network / Adjacent / Local / Physical | 0.85 / 0.62 / 0.55 / 0.20 | same |
| Attack Complexity | Low / High | 0.77 / 0.44 | same |
| Privileges Required | None / Low / High | 0.85 / 0.62 / 0.27 | 0.85 / 0.68 / 0.50 |
| User Interaction | None / Required | 0.85 / 0.62 | same |
| C, I and A impact | High / Low / None | 0.56 / 0.22 / 0.00 | same |
| Maximum sub-score | Impact / Exploitability | 5.873 / 3.887 | 6.048 / 3.887 |
| Severity band | None 0.0 · Low 0.1–3.9 · Medium 4.0–6.9 · High 7.0–8.9 · Critical 9.0–10.0 | ||
The maximum impact figures come from evaluating each formula at ISS = 0.914816: 6.42 × 0.914816 = 5.8731 unchanged, and 7.52 × 0.885816 − 3.25 × 0.894816¹⁵ = 6.0477 changed.
The scoring judgements analysts get wrong
- Rating Privileges Required by what the attacker gains. It measures what they must already hold. A flaw that turns an ordinary user into root is PR:L, not PR:H.
- Marking Scope Changed for any privilege escalation. Scope changes when the impact crosses to a component under a different security authority — a hypervisor escape, a container break-out, a same-origin bypass. Gaining root on the same host is Scope:Unchanged.
- Setting Attack Complexity High because exploitation is difficult to write. AC measures conditions outside the attacker's control at exploit time, not the skill needed to build the exploit. A hard-to-develop but perfectly reliable exploit is AC:L.
- Scoring User Interaction Required because an admin has to install the patch. UI refers to a user action needed for the attack to succeed, such as opening a document or visiting a page.
- Rating impact against the business rather than the component. CVSS asks about the impacted component's confidentiality, integrity and availability. Business consequence belongs in the environmental metrics.
- Using a High availability impact for a brief performance dip. High means total or sustained loss of availability; a slowdown the service recovers from is Low.
- Treating the base score as risk. Risk needs exposure and asset value. A base score is one input to it, and comparing base scores across assets of different value ranks the wrong thing.
- Comparing v2 and v3.1 scores. The scales are not compatible. A v2 7.5 and a v3.1 7.5 do not describe the same severity, and mixing them in one queue produces incoherent priorities.
Why the score never rounds down
CVSS v3.1 defines Roundup to return the smallest number, to one decimal place, that is greater than or equal to the input. Computationally it multiplies by 100,000, rounds to an integer, and steps up to the next tenth unless the value already sits exactly on one. So 7.482243 becomes 7.5 and 6.006968 becomes 6.1, even though ordinary rounding would give 7.5 and 6.0 respectively.
The integer arithmetic exists because v3.0 specified rounding in terms of floating-point values, and a handful of scores — 4.02 was the notorious one — could not be represented exactly and rounded the wrong way, so different implementations disagreed. If you are reconciling a hand calculation against a scanner, this is almost always where the discrepancy is.
CVSS among the other severity systems
CVSS is one of three layers you will meet in vulnerability management, and they answer different questions. CWE classifies the type of weakness — a buffer overflow, an injection, a path traversal — and is what you use to spot patterns across findings and to decide what to fix in the development process rather than in one binary. CVE identifies a specific instance in a specific product. CVSS rates the severity of that instance. A finding needs all three to be actionable.
Exploit-prediction scoring adds the dimension CVSS explicitly lacks: the probability that a vulnerability will actually be exploited in the wild in the next thirty days. Combining a severity score with an exploitation probability produces a far better queue than either alone, because the large majority of published vulnerabilities are never exploited, and CVSS cannot tell you which.
CVSS v4.0 was published in 2023 and restructures the metric groups — splitting exploitability into attack requirements and adding supplemental metrics for automatability and recovery — precisely to address the compression and the risk-versus-severity confusion described above. Adoption is gradual, and v3.1 remains the version most advisories, scanners and compliance regimes are keyed to, which is why it is the version implemented here. When you record a score, always record the version alongside it.
For the arithmetic underlying two other common security judgements, see the key brute-force time calculator for how key length translates into attacker work, and the password entropy calculator for the search space a credential actually presents.