CVSS Vulnerability Score Calculator

What a CVSS base score actually tells you

The Common Vulnerability Scoring System is the number you see attached to almost every published CVE — the 9.8 on a headline remote-code-execution bug or the 5.4 on a stored XSS finding. The base score is a 0-to-10 measurement of a vulnerability's intrinsic technical severity: how reachable the flaw is and how badly it wrecks the affected system, assuming nothing about your specific network. This tool implements the CVSS v3 base metric group defined by FIRST.org, so you set eight metrics and get back the score plus the vector string that appears next to it in advisories.

Two ideas do the heavy lifting. Exploitability asks how hard the vulnerability is to reach and trigger — can an attacker hit it from across the internet, do they need an account, does a user have to click something? Impact asks what breaks once it fires, measured against the three properties every security model cares about: confidentiality (data disclosure), integrity (data tampering), and availability (uptime). A flaw that is trivial to reach but leaks nothing scores low; one that is hard to reach but hands over the whole box can still score high.

How the base score is calculated

The two sub-scores are combined and clamped to a maximum of 10. The overall shape is:

$B=r(I+E)$, where $r$ is the scope multiplier — 1.08 when Scope is Changed and 1 otherwise. $I$ is the impact sub-score and $E$ the exploitability sub-score. Exploitability itself is $8.22$ times the four exploitability weights multiplied together (attack vector × attack complexity × privileges required × user interaction), so weaker attacker requirements pull the score up.

The impact sub-score is $I=f(C,I,A)$. Rather than adding the three impact weights, CVSS combines them so that a second or third affected property adds less than the first: the raw impact $\mathrm{ISC}$ is $1-(1-C)(1-I)(1-A)$, which is why a bug that hits all of C, I, and A does not simply score three times a bug that hits one.

Setting the eight metrics

Each dropdown maps to one CVSS metric. Pick the option that describes the worst realistic case for the flaw:

• Attack Vector — how close the attacker must be. Network means reachable across the internet; Adjacent needs the same subnet or Bluetooth range; Local needs a shell or a lured user; Physical needs hands on the device.
• Attack Complexity — Low if the exploit works every time, High if it depends on a race condition, a specific configuration, or winning a memory-layout gamble.
• Privileges Required — the account level the attacker needs before starting: None, a normal Low user, or High administrative rights.
• User Interaction — None if the attacker acts alone, Required if a victim has to open a file or click a link.
• Scope — Unchanged if the damage stays inside the vulnerable component's security authority, Changed if it escapes it (a sandbox breakout or a hypervisor escape is the classic Changed case).
• Confidentiality / Integrity / Availability impact — None, Low, or High for each, describing how much data leaks, how much can be altered, and how much service is lost.

Choosing Changed for Scope quietly does two things: it applies the 1.08 multiplier and it raises the weight of Privileges Required (Low becomes 0.68 and High becomes 0.50), because breaking out of one component's authority is worth more when you started with fewer rights. This calculator handles that adjustment for you.

Turning the number into a severity band

The score is rounded up to one decimal place and dropped into one of four qualitative bands. Most teams key their patch deadlines off the band rather than the raw decimal — a Critical gets an emergency window, a Low waits for the next scheduled maintenance:

The vector string, and why it matters more than the number

Every calculation produces a vector string like AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. It is a shorthand for exactly which options you picked, and it is the part worth copying into a ticket or advisory. The bare number is lossy — a 6.5 could come from a dozen different metric combinations — but the vector is reproducible: anyone can paste it into a calculator and get the same score, and reviewers can argue with a specific choice ("why did you mark this Network when it needs LAN access?") instead of the total. That is why the National Vulnerability Database and vendor advisories always publish the vector alongside the score, and why this tool outputs both.

What the base score deliberately ignores

The base score is frozen in time and blind to your environment by design — that is what makes a published CVE score comparable across every organization. Two other metric groups, which this calculator does not compute, exist to layer that context back on. Temporal metrics move the score as the world changes: a working exploit appears on GitHub, a vendor ships a patch, or a workaround becomes available. Environmental metrics let you re-weight the impact for your own network — bump availability if the affected host runs your payment gateway, or drop confidentiality if the box holds nothing sensitive.

The practical upshot is that the same base number can mean very different things. A 7.5 on an internet-facing login service with public exploit code deserves a faster response than a 7.5 on an isolated lab machine no one can reach. Treat the base score as a starting point and note the surrounding context in the ticket rather than letting the decimal decide everything.

Worked example: an unauthenticated SQL injection

Say a scanner finds SQL injection in a public web app's login form, reachable from the internet with no account and no user action. You would set Attack Vector to Network (0.85), Attack Complexity to Low (0.77), Privileges Required to None (0.85), and User Interaction to None (0.85). Scope stays Unchanged because the database lives inside the same application authority. Because the injection can dump customer records, tamper with rows, and drop tables, all three impacts are High (0.56 each).

The exploitability sub-score works out to 8.22 × 0.85 × 0.77 × 0.85 × 0.85 ≈ 3.89. The raw impact is 1 − (0.44)³ ≈ 0.915, and for Unchanged scope the impact sub-score is 6.42 × 0.915 ≈ 5.87. Their sum, 9.76, rounds up to 9.8 — Critical — with the vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Flip User Interaction to Required and the score falls to 9.3; flip Attack Vector to Local as well and it drops into the 7s, which is exactly the kind of sensitivity the metrics are meant to capture.

Why the v3 metrics look the way they do

CVSS grew out of a mid-2000s effort to replace a patchwork of vendor-specific severity labels with one shared scale. Version 2 caught on but drew fair criticism for being coarse and easy to game, which produced the v3 redesign this tool uses. The Scope and User Interaction metrics are the clearest fingerprints of that redesign: v2 could not distinguish a bug that stays trapped in a sandbox from one that escapes it, nor a wormable server flaw from one that needs a victim to click. If you ever compare a modern score against an old v2 advisory, expect them to disagree — they are measuring slightly different things.

Using scores across a whole backlog

Scoring one bug is easy; the value shows up when the same rules run over hundreds. Teams that feed scanner output through consistent CVSS logic can sort a backlog by severity, set patch SLAs per band, and watch how many High and Critical findings stay open over a release. Storing the vector string next to each finding — in the ticket, the commit message, or a log line — keeps that history auditable, so six months later you can see not just that something was a 7.8 but why. Automation keeps the scoring consistent, but a human still has to judge the environmental context the base score omits.

What this calculator does and doesn't cover

It computes the CVSS v3 base score only — the eight metrics above — and stops there. It does not apply temporal or environmental adjustments, and it does not model the newer CVSS v4.0 metric set, whose formula and vector format differ. The v3.0 and v3.1 base scores are computed identically here; the small rounding refinement v3.1 introduced won't change the band you land in. For a formal advisory or a dispute over a published score, pair this result with the FIRST.org specification and the judgment of someone who knows the affected system.