A base score is severity, not risk

This is not a caveat we invented to be careful. FIRST, which owns CVSS, says it directly in the specification: the base score reflects the intrinsic characteristics of a vulnerability, and it is not a measure of risk on its own. Risk needs the two things a base score deliberately excludes — whether anyone is exploiting the vulnerability, and what the affected system is worth to you.

The practical consequence shows up in every patch queue sorted by CVSS. A 9.8 in a library you do not load is not urgent. A 6.5 in an internet-facing appliance with a working exploit in the wild is. Sorting by the number alone reliably puts the second one below the first, which is why CVE triage exists: it ranks a list of CVE IDs by exploitation evidence before severity. For a single vulnerability, CVE Explorer shows whether CISA lists it as known to be exploited.

Most published scores are base-only

CVSS has always had more than one score. Alongside the base metrics there are threat metrics (called temporal in v3.1) describing how real the exploit is today, and environmental metrics describing what the system is worth in your deployment. Both change the answer, sometimes substantially. Almost nothing publishes them.

The reason is structural rather than lazy: a vendor or a CVE numbering authority can describe the vulnerability, but only you know whether the affected host is a test box or the payments database. So the number you see quoted in an advisory is nearly always the base score, and it is the maximum the vector allows — every undefined threat and environmental metric is scored at its worst case. Set E:U on a v4.0 vector, or the environmental requirements to Low, and watch the score fall. That drop was always available; nobody had claimed it.

This is also why the tool labels which score it is showing. A number displayed under the word “Base” when it is really an environmental score is how a calculator misleads quietly.

What v4.0 changed

v4.0 is not a re-tuning of v3.1; several metrics mean different things, and a v3.1 vector cannot be mechanically converted into a v4.0 one.

Scope is gone, replaced by subsequent-system impacts. v3.1 had a single yes/no Scope flag saying whether the damage escaped the vulnerable component. v4.0 asks how badly the downstream systems are hit, across confidentiality, integrity and availability separately — SC, SI and SA beside the vulnerable-system VC, VI and VA.
Attack Complexity was doing two jobs and has been split. “The attacker must defeat a mitigation” and “a race has to fall the right way” were both AC:H in v3.1. v4.0 keeps the first as Attack Complexity and gives the second its own metric, Attack Requirements (AT).
User Interaction has three values, not two. v4.0 distinguishes a victim who merely views something (Passive) from one who has to accept a warning or enable macros (Active).
Scoring is a lookup, not a formula. v3.1 computes a score from per-metric weights. v4.0 maps the vector onto one of 270 MacroVector cells and interpolates between that cell and the next lower one, which is why you cannot reproduce a v4.0 score with a pocket calculator.
Scores are named for what they include. CVSS-B is base only; CVSS-BT adds threat; CVSS-BE adds environmental; CVSS-BTE has both. This tool shows the nomenclature next to the number, because “9.3” alone does not say whether anybody considered exploitation.

How this calculates

v3.1 is implemented here from the published specification — the exploitability and impact sub-scores, the scope-changed branch, the temporal multipliers, and the environmental re-run with the modified metrics. It includes CVSS's own rounding rule, which rounds up to one decimal place rather than to the nearest: a raw 8.51 is 8.6, not 8.5. That rule is the classic source of an off-by-0.1 disagreement between calculators, and getting it wrong changes nearly half of all possible base scores.

v4.0 calls FIRST's own reference implementation, which is published under a BSD 2-Clause licence and included here with its copyright notice intact. Reimplementing about 250 lines of interpolation across five equivalence classes would trade a real risk of quietly producing a wrong severity for no benefit to anyone reading a score, so we did not. The parsing, the vector handling and the explanations are ours; the v4.0 arithmetic is theirs.

Both paths are checked by a test suite that sweeps the entire v4.0 base metric space — every combination — against FIRST's engine, enumerates the whole v3.1 base space for the structural properties a score must satisfy, and pins published scores for well-known vectors. Nothing here calls out to a scoring service.

Nothing you type leaves this page

The scoring makes no request of any kind. There is no scoring API behind this page, and nothing you type is transmitted — the scoring code is a JavaScript module the page loads once, and every metric change after that is computed in the tab. You can confirm it: open your browser's network panel and change a metric. Nothing goes out.

That matters more than it might sound. A vector you are building for an unpublished internal finding describes a live weakness in a system you run, usually before it is fixed. Pasting that into a form which posts it somewhere is a disclosure.

Two things about this page do reach the network, and it is better to name them than to let “runs in your browser” imply otherwise. Like every tool here, the page sends one usage beacon when it loads, and that beacon contains the tool name and nothing else — not the vector, not the query string, not an identifier. And the permalink puts the vector in the URL, which means that if you arrive by a permalink, the beacon request carries that URL to our own server as its referrer. Building a vector from scratch never does this; opening someone's shared link does. If a vector is sensitive enough for that to matter, use the calculator directly rather than passing links around.