Understanding CVSS Scoring: How to Rate Your Bugs Like a Pro
October 06, 2026

Understanding CVSS Scoring: How to Rate Your Bugs Like a Pro

A report that opens with "Critical vulnerability, urgent" and nothing else is a report a triage team will argue with. Sometimes they will downgrade it, sometimes they will close it as informational, and occasionally they will be right to do so. The Common Vulnerability Scoring System exists to replace that argument with arithmetic. Learn it well and you stop guessing at severity, start predicting how a program will read your finding, and write reports that are harder to dismiss.

What CVSS Actually Measures

CVSS is a severity framework maintained by FIRST, and it is currently split between version 3.1, which still dominates bug bounty triage, and version 4.0, which most large programs are gradually adopting. Both do the same basic job: they take a set of observable characteristics about a vulnerability and produce a number from 0.0 to 10.0, mapped to a qualitative band.

The bands are simple. Low runs from 0.1 to 3.9, Medium from 4.0 to 6.9, High from 7.0 to 8.9, and Critical from 9.0 to 10.0. Anything scoring 0.0 is a non-issue in CVSS terms.

What CVSS does not measure is risk. Risk involves your target's business context, the value of the data behind the bug, how likely someone is to find and use it, and whether compensating controls exist. CVSS gives you the severity half of that conversation. Nothing more.

The Base Metrics, Grouped

Base metrics describe the vulnerability as it exists, independent of time and environment. In CVSS 3.1 there are eight, and it helps to think of them in two families.

Exploitability metrics

  • Attack Vector (AV) — Network, Adjacent, Local, or Physical. Network means remotely reachable, which is the worst case and the most common in web targets.
  • Attack Complexity (AC) — Low or High. High is reserved for conditions an attacker cannot reliably control, such as winning a race condition or guessing a value that changes.
  • Privileges Required (PR) — None, Low, or High. None means an anonymous attacker.
  • User Interaction (UI) — None or Required. Required means somebody has to click, open, or visit something.

Impact metrics

  • Scope (S) — Unchanged or Changed. Changed means the vulnerable component can affect resources beyond its own security authority, such as escaping a container or crossing a trust boundary.
  • Confidentiality (C) — None, Low, or High. Your reading of what data leaks.
  • Integrity (I) — None, Low, or High. What an attacker can modify.
  • Availability (A) — None, Low, or High. What they can take down or degrade.

Version 4.0 reorganises this considerably, adding Attack Requirements, splitting impact into vulnerable-system and subsequent-system consequences, and grouping metrics into Base, Threat, Environmental, and Supplemental sets. The official FIRST calculator is the only reliable way to convert a vector into a number, so always generate scores there rather than by hand.

Scoring a Reflected XSS, Step by Step

Take a reflected cross-site scripting bug in a search parameter, reachable without login, that fires when a victim clicks a crafted link. Nothing is stored, and the script runs in the origin of the target site.

  1. Attack Vector is Network. The payload travels over HTTP.
  2. Attack Complexity is Low. No unusual conditions are needed.
  3. Privileges Required is None. The attacker is anonymous.
  4. User Interaction is Required. The victim must click the link.
  5. Scope is Changed. The injected script executes in the site's origin and can act on behalf of the user, crossing a boundary.
  6. Confidentiality and Integrity are Low, Availability is None. Session data or page content can be read and altered, but the app stays up.

That produces the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N, which scores 6.1, Medium. Plenty of hunters would call this critical in the title and then wonder why the payout felt small. The vector explains the program's reasoning before they have to explain it to you.

For contrast, an unauthenticated SQL injection that lets you read the entire database but not write to it scores 7.5, High, using CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N. Same "critical" label from the hunter, very different number, and programs price accordingly.

Temporal, Environmental, and the Missing Context

Temporal metrics cover exploit maturity and remediation confidence. Environmental metrics let an organisation adjust for its own architecture, for example by raising Confidentiality when a database holds payment records. Most public bug bounty programs ignore both in triage because they describe the vendor's world, not the bug's.

If you want to show real-world urgency, express it in prose and point to evidence: a public proof-of-concept, active scanning, or a FIRST EPSS percentile where the program publishes one. A paragraph of reasoning is worth more than an inflated vector nobody trusts.

Why Your Score Changes Your Triage and Payout

Severity is not the only input to a bounty, but it is usually the first filter. It sets internal SLAs, decides which team picks up the ticket, and often feeds directly into a reward band. A few practical consequences:

  • Accurate scores build credibility. A hunter who submits a 6.1 and calls it a 6.1 gets taken seriously the next time they submit a 9.1.
  • Inflated scores invite downgrades. When a program has to argue a score down, the whole report reads as less reliable, including the parts you got right.
  • Understated scores cost you money. If you mark a genuine High as Medium because you did not check for Scope Changed or did not notice the bug is unauthenticated, you have negotiated against yourself.
  • The vector is a communication tool. Reviewers can disagree with one metric instead of the whole report, which keeps the conversation technical rather than personal.

Five Scoring Mistakes That Cost Hunters Money

  1. Marking User Interaction as None when a victim click is required. This is the single most common inflation in web reports.
  2. Ignoring Scope Changed on bugs that break out of a sandbox, an iframe policy, or a shared origin.
  3. Scoring a bug you cannot actually reach. If it depends on a misconfiguration you never confirmed, say so instead of scoring the theoretical version.
  4. Scoring the impact you imagined rather than the impact you demonstrated. Show the data you read or the record you changed.
  5. Mixing versions. A 4.0 vector with 3.1 numbers will be flagged immediately. Pick one, state it, and use the matching calculator.

Score It Twice, Explain It Once

Build the vector, generate the number with the official calculator, then read your own report as a triage engineer would. Ask whether every metric is backed by evidence in the write-up, and whether the impact section and the vector tell the same story. Include the vector string inline with your severity line, add one short paragraph justifying the two metrics people argue about most, Attack Complexity and User Interaction, and stop there.

The hunters who get predictable payouts are not the ones who shout loudest. They are the ones whose severity numbers hold up under scrutiny, because a number nobody can argue with is a number nobody can talk down.

Photo: RDNE Stock project / Pexels

Previous Post

Transitioning from IT Security to Full-Time Bug Bounty: A Realistic Roadmap

Related Posts

About Us

Bug Hunter Journal

Bug Bounty

Notes from the front lines of bug hunting.

Read More

Latest Post

Understanding CVSS Scoring: How to Rate Your Bugs Like a Pro
Transitioning from IT Security to Full-Time Bug Bounty: A Realistic Roadmap
How to Automate Your Recon with Subfinder, httpx, and Nuclei
From Zero to P1: A Writeup of a Critical Authentication Bypass

Notes from the front lines of bug hunting.