CVSS Calculator
Pick the base metrics for CVSS v3.1 or v4.0 and get the base score and severity, or paste a CVSS:3.1/ or CVSS:4.0/ vector string to decode and score it. Calculation runs entirely in your browser. Temporal/Threat and Environmental metric groups are not included yet.
About this tool
The Common Vulnerability Scoring System turns a set of categorical judgements about a vulnerability — how it is reached, what it takes to exploit, what it costs you — into a single 0.0–10.0 base score and a severity label. This tool builds that score two ways: pick each base metric from its button group and watch the score and the canonical vector string update, or paste an existing CVSS:3.1/ or CVSS:4.0/ vector and have it decoded back into the selections. It implements the FIRST specifications for v3.1 and v4.0 base metrics; the Temporal/Threat and Environmental groups are not included. Everything is computed in your browser — no vector or score is sent anywhere.
When to use it
Questions
What is a CVSS vector string?
It is the full set of metric choices behind a score, written as slash-separated key:value pairs after a version tag — for example CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. The vector is the real artefact; the number is just its arithmetic. Always publish the vector alongside the score, because only the vector lets someone see which assumptions produced it and re-score it if their environment differs.
What changed in CVSS v4.0 and why?
v3.1 was criticised for score compression — most real vulnerabilities landed between 7 and 10 — and for a Base score that people treated as a risk score even though it deliberately ignores context. v4.0 adds finer Base metrics (Attack Requirements, and User Interaction split into Passive/Active), replaces the Scope switch with explicit Vulnerable-System and Subsequent-System impact metrics, renames Temporal to Threat, and pushes hard on the message that Base alone is not risk. It also adds supplemental metrics (Safety, Automatable, Recovery, and others) that carry information without changing the number.
What is the difference between the Base, Temporal/Threat and Environmental groups?
Base captures the intrinsic, unchanging properties of the vulnerability and is the only group most published scores use. Threat (v4.0) / Temporal (v3.1) adjusts for the current state of exploitation — is there mature exploit code in the wild. Environmental lets you re-weight the score for your own deployment: how important confidentiality, integrity or availability is for the affected asset, and any mitigations already in place. A score that uses only Base is by design a worst-plausible-case, context-free figure.
Why can a score here differ from the one on NVD?
NVD analysts make their own metric choices from the vendor advisory, and reasonable people disagree — especially on Attack Complexity, Privileges Required, User Interaction and Scope. A vendor may also publish a different vector than NVD. If your metric selections match NVD's vector exactly, the numbers will match; if the number differs, compare the vectors segment by segment to find the metric you each judged differently.
What did "Scope" mean in v3.1 and how did v4.0 replace it?
In v3.1, Scope:Changed meant the exploited component and the impacted component were different security authorities — a VM escape, or a browser sandbox break. It was a single binary flag that inflated the score and confused many assessors. v4.0 drops it and instead asks directly for impact on the Vulnerable System (VC/VI/VA) and on any Subsequent System (SC/SI/SA), so a container escape is expressed as low impact on the vulnerable system but high impact on the subsequent one, with no special toggle.
Is a 9.8 always operationally worse than a 7.5?
No. Base score measures technical severity under worst-case assumptions, not risk to you. A 9.8 on an internal service with no sensitive data, reachable only from a segmented network, may matter far less than a 7.5 on an internet-facing system holding customer records — particularly if the 7.5 is being actively exploited. Use Base to triage, then apply Environmental metrics, exploitation data (EPSS, KEV) and your own asset knowledge before deciding what to fix first.
How do CVSS, EPSS and the CISA KEV catalog relate?
They answer different questions. CVSS base score asks how bad the vulnerability is if exploited. EPSS is a data-driven probability that a given CVE will be exploited in the next 30 days. The CISA Known Exploited Vulnerabilities catalog is a binary list of CVEs with confirmed in-the-wild exploitation. A mature prioritisation uses all three: CVSS for impact, EPSS for likelihood, KEV as an override that jumps something to the top regardless of its score.
How is the v4.0 score actually computed?
v4.0 does not use a closed-form formula like v3.1. Each vector maps to a MacroVector — a compressed profile of its metric values grouped into equivalence classes. A lookup table gives the score for that MacroVector, then the algorithm interpolates: it measures how far your specific vector sits from the most and least severe vectors in the same MacroVector and adjusts the score proportionally. This tool ports the FIRST reference implementation, including its lookup data, so results track the official calculator.
Can I trust a score I calculated myself?
A CVSS score is only as good as the metric choices behind it — the arithmetic is fixed and this tool follows the spec, but garbage judgements produce a confident-looking wrong number. The metrics most often misjudged are Attack Complexity (it is not "how hard is the exploit" but "are there conditions outside the attacker's control"), Privileges Required, and User Interaction. Read the FIRST specification's definitions for each metric, document your reasoning, and always publish the vector so others can check it.