CVSS Score Calculator

A CVSS score is a compressed opinion about one vulnerability. A handful of answers about the flaw go in, a single number from 0.0 to 10.0 comes out, and nearly all of the meaning lives in the answers.

The Common Vulnerability Scoring System is maintained by FIRST, the Forum of Incident Response and Security Teams. It publishes the specifications, the user guides and the worked examples, and it licenses the system to everyone freely on two conditions: give attribution, and whenever you publish a score, publish the vector string it came from. The second condition is the important one. A bare 9.8 says almost nothing about why a flaw is serious or whether those reasons apply to you. The vector records every answer, so another analyst can check the reasoning and compute the number again.

The system grew out of research by the National Infrastructure Advisory Council, and its first version appeared in February 2005. Version 2 followed in June 2007 and version 3.0 in June 2015. Version 3.1, released on 17 June 2019, kept the metrics but redefined the Roundup function and one Environmental formula. Version 4.0 arrived in November 2023 and replaced the scoring method entirely.

What the Base score measures is deliberately narrow. Both user guides carry a section that says, in nearly these words, that CVSS measures severity, not risk. The Base metrics describe intrinsic properties of the flaw: how far away an attacker can be, how hard the attack is, what privileges and user actions it needs, and how badly confidentiality, integrity and availability suffer. Those properties do not change from one organisation to the next, which is why a vendor can score them once for everybody. The guides then add that a Base score should be supplemented, and that a real risk assessment weighs things CVSS leaves out, such as exposure and threat.

Properties of the flaw, properties of your situation

The metric groups split along exactly that line. Base metrics belong to the vulnerability. Temporal metrics in version 3.1, renamed Threat in version 4.0, belong to the state of the world: whether working exploit code exists and, in 3.1, whether a fix is out and how confident the report is. Environmental metrics belong to you. They let an analyst say that confidentiality matters a great deal for this asset, or that a service the vendor assumed was reachable from the whole Internet is reachable here only from an adjacent network.

The direction of the Threat adjustment surprises people. It can only lower a score. The version 4.0 FAQ explains why: providers score the reasonable worst case, assuming every flaw will be exploited and weaponised, so the Base score is already the ceiling. Evidence that nobody attacks the flaw, and that no proof-of-concept code is public, is what brings it down.

Environmental values can move a score either way. Security requirements weight the impacts up or down, and modified metrics can make a remote flaw local or a local one remote.

Take the Heartbleed bug, one of FIRST’s own version 3.1 examples, scored CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N. The impact sub-score is 1 minus the product of 0.44, 1 and 1, which is 0.56. With scope unchanged, Impact is 6.42 times that, or 3.5952. Exploitability is 8.22 times 0.85 for Network, 0.77 for Low complexity, 0.85 for no privileges and 0.85 for no user interaction, about 3.8870. The sum is 7.4822, and the specification’s Roundup lifts it to 7.5, the High score the examples document publishes. Paste that vector into the calculator above and the same intermediate values appear beside the dial.

Now describe a situation. Unproven exploit code, an official fix and a confirmed report, written E:U/RL:O/RC:C, multiply the Base score by 0.91, 0.95 and 1. That gives 6.48375, which rounds up to a Temporal score of 6.5. Add a Low Confidentiality Requirement, CR:L, and the modified impact halves to 1.7976; the Environmental score comes out at 5.0, Medium. Nothing about the flaw changed. Only the answers about the world and the asset did.

How version 4.0 changed the arithmetic

Version 3.1 is a formula. Version 4.0 is closer to a ranked table. Its user guide describes how the special interest group gathered about 15 million possible combinations of Base, Threat and Environmental values into 270 equivalence sets and asked experts to compare them. The sets were put in order from least to most severe, and that order was fitted into the 101 available scores while keeping the old boundaries between Low, Medium, High and Critical. Each set is called a MacroVector. Its score comes from a lookup table published in FIRST’s open source calculator repository, which the specification itself names as the source of the scores.

A vector inside a MacroVector is then nudged down by interpolation. For each group of metrics, the method counts how many single steps the vector sits below the most severe vector of its MacroVector, divides by the depth of that MacroVector, and multiplies by the score gap to the next lower one. The mean of those proportional distances is subtracted from the MacroVector score and the result is rounded to one decimal. The stated aim is that changing any metric value changes the score where possible, without moving it further than the uncertainty in the experts’ ranking.

Heartbleed rescored under version 4.0 shows the mechanism. The vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N falls in MacroVector 001200, whose table score is 8.8. In the impact group it sits three steps below the most severe vector, the depth there is 8, and the next lower MacroVector scores 8.0, so that group contributes 0.8 times 3/8, or 0.3. Four groups have a lower neighbour and the other three contribute nothing, so the subtraction is 0.075 and the score is 8.7. That matches the 8.7 FIRST publishes for this flaw with Exploit Maturity set to Attacked, which is also what an unset Exploit Maturity assumes.

The vocabulary moved too. Scope is gone, replaced by separate impacts on the vulnerable system and on subsequent systems. Attack Requirements splits deployment conditions out of Attack Complexity, and User Interaction gained Passive and Active. Remediation Level and Report Confidence were retired.

Labels changed with it. A version 4.0 number should be written as CVSS-B, CVSS-BT, CVSS-BE or CVSS-BTE according to which groups were assessed, because every v4.0 score is computed with all groups present, defaults included. Supplemental metrics such as Safety, Automatable and Recovery travel in the vector but never alter the score. A score without its label is easy to misread.

Reading a vector and scoring a backlog

A vector string is a small contract with strict grammar. It starts with CVSS:3.1/ or CVSS:4.0/, each metric appears once, abbreviations and values are case sensitive, and every Base metric is mandatory. Version 3.1 accepts any order but prefers one. Version 4.0 is stricter: any order other than the one in its table is invalid. The specification even lists failing samples, among them an Attack Vector of F, a lowercase ui and an Exploit Maturity given twice.

Those rules matter more than they look. A reader that quietly accepts a duplicated metric has to pick one of the two values, and different readers pick differently. A missing prefix leaves the version to guesswork, and the same letters mean different things across versions: S is Scope in 3.1 and Safety in 4.0. Two of the environmental variations in FIRST’s own version 4.0 examples list their metrics out of the fixed order, which a strict reader rejects. This calculator names that fault and offers to normalise the order.

Exactness is the other half. The version 3.1 specification spends an appendix on floating point, because a naive Roundup turns 0.1 plus 0.2 into 0.4; its suggested method multiplies by 100,000 and finishes in whole numbers. Version 4.0 has its own edge. Where the interpolated value lands exactly on a half, binary arithmetic and exact fractions can round apart. In this tool’s own checks that happened for 1,412 of the 419,904 Base and Exploit Maturity combinations. The calculator follows FIRST’s calculator there and says when a vector is one of them.

For a backlog, consistency beats precision. Score every item with the same version, keep the vector beside the number, and decide in advance which groups you will fill in. A list where some items carry Environmental values and others do not cannot be ranked by score alone, which is the very problem the version 4.0 labels address. The consumer implementation guide describes enrichment as a maturity model, from Base scores alone up to full vectors with threat and environmental data, and warns that a higher level is not a measure of accuracy. It measures how much of your situation the number contains.

Some things no CVSS calculation can do. It cannot choose the metric values; that judgement belongs to whoever understands the flaw. It cannot tell you whether anyone is attacking the flaw today. CISA’s Known Exploited Vulnerabilities Catalog lists flaws exploited in the wild, and FIRST’s Exploit Prediction Scoring System estimates the probability of exploitation within the next 30 days. CISA’s Stakeholder-Specific Vulnerability Categorization ends in actions rather than numbers. The version 4.0 FAQ calls these complements, not replacements.

Even the version 3 equation is an approximation. NIST IR 8409 measured how well the Base score equation matches the expert opinion it was fitted to and found a mean distance of 0.13 points from fully consistent scoring systems, with a maximum of 0.40. That is close, and a reminder that the decimal is not sacred.

Used well, the number is a sorting key with its reasons attached. Keep the vector, label the version and groups, compute it the way the specification says, and then set it beside the facts about your own systems that CVSS was never meant to know.