CVSS 4.0 calculator and scoring guide

What is CVSS 4.0?

CVSS 4.0 is the current version of the Common Vulnerability Scoring System, the open standard FIRST maintains for rating how severe a software vulnerability is. You describe a bug with a short vector string, such as CVSS:4.0/AV:N/AC:L/…, and it produces a score from 0.0 to 10.0 plus a severity: None, Low, Medium, High or Critical.

FIRST published version 4.0 on November 1, 2023, as the successor to 3.1. You will still see 3.1 vectors in advisories and bug bounty programs, so check which version a program asks for before you score. The authoritative source is the FIRST specification; this page is the practitioner's version, written the way reports are triaged in Raw Ops bug hunting competitions.

Two things are worth keeping straight about the standard. It rates severity, which is an intrinsic property of the vulnerability on a specified system, and not risk, which depends on your estate and your threat model. A 9.3 in a lab and a 9.3 on your production payment flow are the same severity and very different priorities. Second, the vector is the finding: two people who disagree about a score almost always disagree about a metric, and the vector is where that disagreement becomes visible and arguable. This is why triage teams argue about vectors rather than numbers.

How CVSS 4.0 scoring works

Version 3.1 used a published arithmetic formula: multiply exploitability sub-scores, combine impact sub-scores, apply a Scope adjustment, round up. Version 4.0 drops that. The specification builds the score in three steps:

1. Group the vector into a MacroVector. The metrics collapse into six equivalence sets (EQ1 to EQ6), each with two or three levels. EQ1 looks at AV, PR and UI together, so AV:N/PR:N/UI:N is level 0, the most severe. The six levels form a six-digit MacroVector such as 000200.
2. Look up that MacroVector's score. Each of the 270 possible MacroVectors has a score, set by expert ranking of real vulnerabilities during the 4.0 design work. 000200 maps to 9.3.
3. Interpolate within it. Vectors sharing a MacroVector are not equally severe. The algorithm measures how far your vector sits from the most severe one in its group, compares that with the gap to the next-lower MacroVector, and subtracts the proportional distance. The result rounds to one decimal place.

The practical takeaway: you cannot score by hand the way you could with 3.1, and a close-enough formula gives wrong answers. The calculator above runs FIRST's reference algorithm, and the MacroVector it shows is a good sanity check: two findings that share a MacroVector will have close scores.

One more consequence follows from the lookup table being built by expert ranking rather than arithmetic: some score movements look surprising. Swapping a High impact for a Low one may barely move the number, while adding one attack requirement can drop it sharply, because the table ranks whole groups rather than weighting each metric independently. Do not read a flat score as a mistake in your vector. Change one metric at a time in the calculator above and watch what happens; that is faster than reasoning about the table and it is how you learn which metrics carry the weight in a given scenario.

What changed from CVSS 3.1 to CVSS 4.0

If you scored bugs with 3.1, these are the differences that change day-to-day scoring:

One consequence: 3.1 and 4.0 scores are not directly comparable, so do not convert them. Re-score the vulnerability from its characteristics. Many findings land close to their old number; others move noticeably. XSS is the common example, because its impact now sits mostly on subsequent systems, which weigh less in the lookup table.

There is a third change worth planning for, because it is the one that catches teams mid-transition: vector strings are not interchangeable between versions. A 3.1 vector and a 4.0 vector with the same letters mean different things, since 3.1 has no AT metric and its UI takes only two values. If you store vectors, key them by version. A report that quotes a score without the vector, or the vector without the nomenclature, cannot be checked by anyone.

The 11 base metrics explained

Five metrics describe how an attacker reaches and triggers the bug. Score them from the attacker's point of view, against the vulnerable system as it is normally deployed.

• Attack Vector (AV): Network for almost every web and API bug, Adjacent for a shared local network or Bluetooth range, Local when local access or a session on the device is needed, Physical for USB or debug-port access.
• Attack Complexity (AC): Low when no target-specific defense must be defeated, High when the attacker must evade ASLR or DEP or obtain a target-specific secret. In 4.0, AC is only about defenses; bad luck belongs in AT.
• Attack Requirements (AT): None when the attack works whenever the code path is reachable, Present when success depends on conditions the attacker does not control, such as winning a race or already sitting on-path. This is the metric that separates works-every-time from works-if-the-stars-align.
• Privileges Required (PR): None for unauthenticated, Low for an ordinary account, which is usually free to create on a public app, and High for administrative control. In multi-tenant SaaS a normal tenant user is Low.
• User Interaction (UI): None when nobody but the attacker is involved, Passive when the victim does something ordinary and involuntary such as loading a page with a stored payload, Active when they must take a conscious action such as clicking a crafted link or dismissing a warning.

The six impact metrics are each None, Low or High. What is new is where the impact happens. The vulnerable system (VC, VI, VA) is the component holding the flaw. Subsequent systems (SC, SI, SA) are anything beyond it that the attack reaches, such as users' browsers, a cloud control plane, a downstream database or other tenants.

High means a total loss, or one serious enough to matter a lot: reading all the data, or any data such as admin credentials that leads to full compromise, modifying anything, or making the service fully unavailable. Low is a limited, constrained loss where the attacker has little control over what is affected. None means no impact on that property.

FIRST's user guide gives XSS explicitly: the web application is the vulnerable system and the victim's browser is a subsequent system. That is why a typical stored XSS scores VC:N/VI:N/VA:N/SC:L/SI:L/SA:N rather than putting impact on the app itself.

Threat metrics, nomenclature and severity

Exploit Maturity (E) is the only threat metric. Attacked (A) means attacks or easy-to-use public exploit tooling exist. POC (P) means a proof of concept is public but there is no known exploitation. Unreported (U) means neither is known. Not Defined (X) is treated as Attacked, the reasonable worst case, which is why adding E:A never changes a base score while E:P and E:U lower it.

Environmental metrics let a consumer re-weight a score for their own deployment. Security requirements (CR, IR, AR) express how much confidentiality, integrity and availability matter for that asset, and modified base metrics (MAV, MAC, … MSA) reflect local mitigations, with a Safety value for impacts that could injure people. This calculator covers base and threat metrics; use FIRST's full calculator for environmental scoring.

Always label a score with the groups it includes. CVSS-B is base metrics only, which is what vendors and researchers usually publish. CVSS-BT adds threat. CVSS-BE adds environmental, and CVSS-BTE adds both, which is the closest the standard gets to a risk-informed priority for your organization.

The qualitative severity scale is unchanged from 3.1 and is the part most people already know: None is exactly 0.0, Low runs 0.1 to 3.9, Medium 4.0 to 6.9, High 7.0 to 8.9 and Critical 9.0 to 10.0. If all six impact metrics are None the score is 0.0 whatever the exploitability values say, which is worth remembering when a report describes a real weakness that on its own simply costs the attacker nothing.

Two practical habits follow. First, write the vector before you argue about the number: a vector forces each metric to be a defensible claim, and it is the part a reviewer can check against your proof of concept. Second, re-score when the facts change. A finding that gained a write primitive or reached a further system is a different vulnerability for scoring purposes, and chasing that second step is usually where the highest-severity reports come from.

The glossary defines the terms this page uses in passing, including vector, MacroVector, CWE and PoC, and the report template has a fully worked IDOR example with a rationale for every metric.

Worked examples for web and API vulnerabilities

These five findings come up constantly in VAPT engagements, bug bounty programs and Raw Ops competitions. Each one is a preset in the calculator above. Your own scoring may differ if your facts differ, and that is expected: what matters is that you can defend every metric choice.

1. IDOR exposing other customers' invoices

Finding: GET /api/v2/invoices/{id} checks that you are logged in but not that the invoice is yours, so any registered user can iterate IDs and download every customer's invoice, including names, addresses and GST numbers.

• AV:N / AC:L / AT:N: a plain request that works every time.
• PR:L: needs a normal self-registered account. UI:N: no victim action.
• VC:H: all customers' invoice data can be read. VI:N / VA:N: read-only.
• SC/SI/SA:N: the impact stays inside the application.

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Score: 7.1 High (CVSS-B) · MacroVector 101200

If the same flaw also accepts PUT, so you can edit other customers' records, it becomes VI:H and scores 8.6 High. If it exposes only one non-sensitive field, VC:L gives 5.3 Medium.

2. Stored XSS in support-ticket comments

Finding: a logged-in user can post a ticket comment containing <img src=x onerror=…>, which runs in the browser of anyone who opens the ticket, including support agents. Session cookies are HttpOnly, so the payload can act as the victim within the page but cannot steal the cookie.

• AV:N / AC:L / AT:N / PR:L: any user can post a comment.
• UI:P: the victim only views the ticket, which is passive. A reflected XSS needing a click on a crafted link would be UI:A.
• VC:N / VI:N / VA:N: the application itself is not compromised.
• SC:L / SI:L / SA:N: limited read and act-as-user capability in the victim's browser, which is the subsequent system.

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N
Score: 5.1 Medium (CVSS-B) · MacroVector 102201

This matches FIRST's own stored-XSS example, CVE-2020-0926. If you can show the payload taking over an administrator's session and changing application settings, argue for SC:H/SI:H at 6.3 Medium, or chain it into a separate finding for the admin-side impact.

3. Unauthenticated SQL injection in a search endpoint

Finding: the q parameter of /search is concatenated into a query. Time-based and UNION payloads confirm it, and the database user has read and write rights on the application schema, so every table can be dumped and modified.

• AV:N / AC:L / AT:N / PR:N / UI:N: anonymous and reliable.
• VC:H / VI:H / VA:H: full read and write access, and tables can be dropped.
• SC/SI/SA:N: no demonstrated impact beyond the application and its database.

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Score: 9.3 Critical (CVSS-B) · MacroVector 000200

…/SA:N/E:P   → 8.9 High (CVSS-BT)  public PoC, no known attacks
…/SA:N/E:U   → 8.1 High (CVSS-BT)  no public exploit or attacks

This is the same base vector FIRST uses for Log4Shell and Shellshock. The threat variants show why E matters for patch prioritization: the same bug drops out of Critical when no exploit is known.

4. SSRF to the cloud metadata service

Finding: a fetch-URL-preview feature requests any URL server-side without authentication. Pointing it at http://169.254.169.254/latest/meta-data/iam/security-credentials/<role> returns temporary credentials for the instance role, because the instance still allows IMDSv1. That role can read and write the company's storage buckets.

• AV:N / AC:L / AT:N / PR:N / UI:N: anonymous and reliable.
• VC:H: the instance's own role credentials are exposed. VI:N / VA:N.
• SC:H / SI:H: with those credentials the attacker reads and modifies data in other cloud services, which are subsequent systems. SA:N unless you demonstrate delete or deny.

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:N
Score: 9.3 Critical (CVSS-B) · MacroVector 001100

Score what you can prove. If IMDSv2 is enforced and the fetch can only read a few internal status pages, the honest vector is closer to VC:L/…/SC:L/SI:N/SA:N at 6.9 Medium. The same bug class covers most of the severity range depending on the environment, which is exactly why reports need evidence rather than just a vulnerability class.

5. CSRF on the change-email endpoint

Finding: POST /account/email has no CSRF token and uses a SameSite=None session cookie, so a logged-in victim who clicks a link to the attacker's page silently changes their account email to the attacker's address.

• AV:N / AC:L / AT:N / PR:N: the attacker needs no account.
• UI:A: the victim must actively visit the attacker's page while logged in.
• VI:H: the attacker controls a security-critical field on the victim's account. VC:N / VA:N for the request itself.

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
Score: 6.9 Medium (CVSS-B) · MacroVector 101200

If you go on to show a full account takeover by triggering a password reset to the new email, many triage teams will accept VC:H as well, at 8.5 High. Document the chain step by step, because that is what earns the higher score.

When to use this, and when to use FIRST's calculator or NVD's

The scores here should match FIRST's own CVSS 4.0 calculator, because the scoring code is the same open-source FIRST / Red Hat engine, ported without changes. If a score you publish will be checked by a vendor, a CNA or NVD, generate the final vector on FIRST's calculator anyway: it is the reference, and citing it ends arguments about tooling. This page adds the metric explanations and worked web and API examples alongside the calculator, and it covers CVSS 4.0 only. For a 3.1 score, which some programs still require, use FIRST's 3.1 calculator or NVD's.

Common CVSS 4.0 scoring mistakes

• Converting 3.1 scores instead of re-scoring. The metric sets differ, so a 3.1 score cannot be translated mechanically.
• Using AC:H for needs luck. Race conditions and on-path requirements are AT:P. AC:H is for defeating security mechanisms.
• Putting browser-side impact on the vulnerable system. For XSS and similar client-side bugs the impact goes in SC, SI and SA.
• Scoring the worst imaginable chain. Score the impact you demonstrated, and report escalation paths separately or as a documented chain.
• Publishing a BT or BTE score without saying so. Always include the nomenclature and the full vector string.
• Treating the score as a priority. A 9.3 on an isolated test box can matter less than a 6.9 on a payment flow. Base scores are severity, and environmental context turns them into risk.

None of these are hard rules, but the mistakes are consistent enough that a reviewer will spot them, and each one costs you score you had earned. Two are the expensive ones. Scoring the worst imaginable chain is the commonest serious error: a reporter who can point at a path to admin but has not demonstrated it has not earned the admin score, and a triage team that accepts it is scoring an assumption. Publishing a threat or environmental score under a plain base label is the most damaging, because it makes a number look comparable with every other number in your spreadsheet when it is not. The cheapest defense is to write the vector while the proof of concept is open, because every metric you set is then attached to the evidence that supports it; scoring afterwards, from memory, is where most of these mistakes come from. If two of your metrics are genuinely borderline, state the assumption in the report so a reviewer can accept it or tell you which way to argue it.

Scoring reports in Raw Ops

Raw Ops is CTF7's report-based competition format, the anti-CTF. There are no flags. Participants investigate a realistic target application or network the way they would on a VAPT engagement and submit vulnerability reports. The organizer's triage team reviews each one, removes duplicates, asks for more information and accepts valid findings. Accepted findings are scored with CVSS 4.0, so a well-evidenced critical SQL injection outranks a pile of low-impact issues, and chaining several weaknesses into a higher-impact path is encouraged.

That makes severity literacy a competitive skill: players who can argue UI:P versus UI:A, or prove subsequent-system impact, score better, and they practice the skill a pentest report needs. If you are preparing for a Raw Ops event, pair this guide with our vulnerability report template. If you are organizing one, see how Raw Ops works or plan an event with our team. Recruiters use the same scores in hiring rounds to see how candidates judge severity, and terms like vector, MacroVector and triage are defined in the glossary.

The organizer-side view matters too, because severity scoring only works if it is applied the same way every time. In a Raw Ops event the triage team needs a written policy answering the questions this page raises: which threat metric, if any, is applied to accepted findings, how duplicates are handled, whether chains get a multiplier, and who has the final say when a reporter and a triager disagree. Publish it with the rules, score every accepted report against the same policy, and keep the per-criterion rationale. An event where identical findings score differently teaches players that the scoring is arbitrary, which is worse than a harsh scale.