CVSS 3.1 calculator with severity rating
Eight questions, a base score, and the vector string to paste into your report or your ticket. Nothing is asked for and nothing is emailed. The arithmetic follows the CVSS version 3.1 specification exactly, including the scope-changed coefficient that most improvised calculators get wrong.
CVSS is the Common Vulnerability Scoring System, and the base score is the part that describes a vulnerability's intrinsic characteristics: how it is reached, how hard it is to use, what the attacker needs first, and what happens when it works. It does not describe your risk. It knows nothing about what the affected system does or who your customers are. Score first, then judge.
Severity ratings
The qualitative rating is a band applied to the numeric score. It is the part most tickets and most contracts reference.
| Base score | Rating |
|---|---|
| 0.0 | None |
| 0.1 to 3.9 | Low |
| 4.0 to 6.9 | Medium |
| 7.0 to 8.9 | High |
| 9.0 to 10.0 | Critical |
What the base score does not tell you
It does not tell you how urgent this is for you. Two systems with the same finding can deserve opposite responses: a critical on an internet-facing service holding customer records is an emergency, and the same critical on an isolated internal tool with two users can wait for the next maintenance window. CVSS excludes that context from the base metrics, which is why environmental and temporal metrics exist as separate groups.
Watch for a report where every finding is rated critical or high. Sometimes that is true. More often it is severity inflation, and it is one of the signals to look for when reading a firm's sample report, on how to evaluate a testing firm. A report that reasons about impact in your context beats one that copies a score from a vendor advisory.
Scope is the metric people get wrong
Scope changed does not mean the impact was large. It means the vulnerable component and the impacted component sit under different security authorities: a hypervisor escape, a browser sandbox break, a flaw in one tenant that reaches another, a cross-site scripting flaw where the vulnerable server causes impact in the victim's browser. It carries a 1.08 multiplier and changes the privileges-required weights as well, so setting it casually moves a score by more than a point.
Using a score in a remediation conversation
Score the finding, then argue about the response separately. Most remediation disputes are disagreements about environmental context conducted in the language of base scores, which nobody wins. Record the vector string alongside the number in your tracker. The vector is auditable and the number on its own is not.
If a testing firm's report gives a score with no vector, ask for the vector. It takes them seconds and lets you check the reasoning. Where you disagree it will almost always be one metric, usually privileges required or scope, and it settles in one sentence rather than a meeting.
Findings you would rather someone else found first
Tell us what needs testing and who asked for it, and we will put one scope in front of Canadian firms.
Get matchedCommon questions
Is this calculator CVSS version 3.1 or version 4.0?
Version 3.1 base metrics. It is still the version most tooling, most vulnerability databases and most contractual language reference, and it is what a penetration test report in Canada will almost always quote today. Version 4.0 restructures the metric groups and produces different numbers, so never compare a 3.1 score with a 4.0 score as though they are the same scale.
Why did my score come out differently from the vendor's?
Almost always one metric, and usually privileges required, user interaction or scope. Vendors score against their own assumed deployment, which may differ from yours: they may assume an unauthenticated attacker where your product only exposes the feature to signed-in users. Compare the two vector strings metric by metric and the difference will be obvious in a few seconds.
Should we use CVSS to decide what to fix first?
As an input, not as the decision. The base score ignores exploit availability, whether the system is reachable from the internet, and what the data is worth, all of which change the answer. A practical ordering is exploitability in your environment first, then data sensitivity, then the base score as a tie-breaker. Using the score alone leads teams to fix a theoretical critical while a medium sits on a public endpoint.
Does an auditor care about our CVSS scores?
They care that you have a defined severity scale, that you apply it consistently, and that your remediation timelines are tied to it and met. CVSS is a convenient scale for that because it is published and external, but the control is the process, not the number. Writing down that critical findings are fixed within thirty days and then showing tickets that prove it is what passes evidence review.
Is this tool gated in any way?
No. There is no email form on this page, nothing is stored, and the calculation runs in your browser. It is here because it is useful and because people who need it are often the same people who later need to scope a test.