CVSS for Pentesters: How to Think About Severity

CVSS stands for Common Vulnerability Scoring System.

It provides a standardized way to describe the severity characteristics of a vulnerability.

For pentesters, CVSS is useful because it creates a shared language between security teams, developers, managers, auditors, and vulnerability management processes.

But CVSS is not a replacement for judgment.

A good pentester should understand both:

CVSS score -> standardized severity signal
Business impact -> why the issue matters in this specific environment

Image: Type: Context. Mô tả: “A severity decision diagram showing technical exploitability, affected data, affected users, privilege level, user interaction, and business context leading to final severity.” caption: “CVSS helps structure severity, but context explains why the score matters.”

Context

When a pentester reports a vulnerability, the reader wants to know priority.

Should the team fix it today, this week, this sprint, or later?

Severity helps answer that question.

CVSS considers technical characteristics such as:

  • How the vulnerability can be reached
  • Whether privileges are required
  • Whether user interaction is required
  • Whether exploitation affects confidentiality, integrity, or availability
  • Whether the impact crosses security boundaries

The exact metric names depend on the CVSS version used by the organization.

As of CVSS v4.0, the framework includes Base metrics and additional metric groups designed to improve clarity and granularity.

CVSS Is Not the Same as Risk

This is important:

CVSS severity is not always the same as business risk.

CVSS describes vulnerability characteristics. Business risk also depends on:

  • Asset criticality
  • Data sensitivity
  • Number of affected users
  • Internet exposure
  • Threat model
  • Compensating controls
  • Detection capability
  • Regulatory requirements
  • Business process affected

Example:

Stored XSS in an internal test app -> lower business risk
Stored XSS in an admin portal used by support staff -> higher business risk

The technical class may be similar, but the impact context is different.

How Pentesters Should Think About Severity

Start with these questions.

1. Is the Vulnerability Remotely Reachable?

Ask:

  • Is the endpoint public?
  • Is authentication required?
  • Is network access restricted?
  • Is the issue reachable from the internet?
  • Does the attacker need internal access?

Public, unauthenticated vulnerabilities usually deserve more attention than vulnerabilities requiring deep internal access.

2. What Privileges Are Required?

Ask:

  • Can an anonymous user exploit it?
  • Does the attacker need a regular account?
  • Does the attacker need a privileged account?
  • Can self-registration provide the required access?

A vulnerability requiring admin privileges may be lower severity unless it enables privilege expansion, data exposure, or tenant compromise.

3. Is User Interaction Required?

Ask:

  • Does a victim need to click a link?
  • Does an admin need to view a page?
  • Does exploitation happen automatically?
  • Is social engineering required?

User interaction does not make a bug harmless, but it affects exploitability.

Example:

Reflected XSS requiring a victim click -> user interaction required
Stored XSS triggered when an admin opens a page -> user interaction likely required but impact may be high

4. What Is the Confidentiality Impact?

Confidentiality means unauthorized data disclosure.

Ask:

  • Can the attacker read another user’s data?
  • Can the attacker read sensitive internal data?
  • Can the attacker access PII, payment data, tokens, invoices, or secrets?
  • Is the exposure limited or broad?

A BOLA issue exposing invoices across tenants can be high severity even if exploitation is technically simple.

5. What Is the Integrity Impact?

Integrity means unauthorized modification.

Ask:

  • Can the attacker change data?
  • Can they modify another user’s profile, order, invoice, or role?
  • Can they approve, cancel, delete, or create business records?
  • Can they alter security settings?

Unauthorized write access is often more serious than read-only exposure.

6. What Is the Availability Impact?

Availability means service disruption.

Ask:

  • Can the issue crash the application?
  • Can it lock users out?
  • Can it exhaust resources?
  • Can it delete or corrupt critical data?
  • Can it block business operations?

Be careful with availability testing. Do not perform destructive or denial-of-service tests unless explicitly authorized.

Practical Examples

Example 1: Missing Security Header

Issue: Missing X-Content-Type-Options header
Reachability: Public
Impact: Defense-in-depth weakness
Business impact: Limited unless chained with content sniffing conditions
Typical severity: Low / Informational depending on context

This should be reported clearly but not exaggerated.

Example 2: IDOR in Invoice API

Issue: User A can access User B's invoice by changing invoice_id
Reachability: Authenticated regular user
Impact: Cross-user billing data disclosure
Business impact: Tenant isolation failure and privacy exposure
Typical severity: High depending on data sensitivity and scale

The issue requires authentication, but self-registration may make exploitation realistic.

Example 3: Stored XSS in Admin Review Panel

Issue: Regular user submits stored XSS that executes when admin reviews it
Reachability: Authenticated user
User interaction: Admin views the page
Impact: Admin session actions or sensitive data exposure depending on controls
Business impact: Potential account takeover chain or privileged action abuse
Typical severity: Medium to High depending on exploitability and session protections

User interaction exists, but the victim role increases impact.

Example 4: Unauthenticated SQL Injection

Issue: Public search endpoint is vulnerable to SQL injection
Reachability: Public unauthenticated endpoint
Impact: Possible data extraction or modification depending on DB permissions
Business impact: Potential broad data compromise
Typical severity: High to Critical depending on confirmed impact

Severity should be based on confirmed or strongly evidenced impact, not only the vulnerability class name.

Image: Type: Test case. Mô tả: “A severity comparison table showing missing header, IDOR, stored XSS, and SQL injection with reachability, privileges, user interaction, and impact columns.” caption: “Severity becomes clearer when technical characteristics are compared side by side.”

Common Pentester Mistakes

Mistake 1: Treating Every XSS as High

XSS severity depends on context:

  • Reflected or stored?
  • Who triggers it?
  • What can JavaScript access?
  • Are cookies HttpOnly?
  • Is CSP present?
  • What role is affected?

The vulnerability class is only the starting point.

Mistake 2: Ignoring Business Data

A technically simple bug can be severe if it exposes sensitive business data.

Example:

GET /api/v1/payroll/{employee_id}

If object-level authorization is missing, the issue may be serious even without complex exploitation.

Mistake 3: Overrating Theoretical Chains

Chained impact should be plausible and evidenced.

Do not claim full account takeover unless the steps are demonstrated or strongly supported.

Better wording:

This issue may support account takeover if combined with a separate session theft condition.

Worse wording:

This is account takeover.

Mistake 4: Reporting a Score Without a Rationale

A number alone is not enough.

Explain the main drivers:

Severity is High because any authenticated user can access invoices belonging to other users, the affected data includes billing information, and exploitation requires only changing a numeric object ID.

A Practical Severity Workflow

Use this workflow:

1. Identify the vulnerability class
2. Confirm affected endpoint and role
3. Determine reachability
4. Determine privileges required
5. Determine user interaction
6. Confirm confidentiality, integrity, and availability impact
7. Assess business context
8. Assign severity
9. Explain rationale clearly
10. Provide remediation priority

Severity Rationale Template

Severity: High

Rationale:
The issue allows any authenticated regular user to access invoices belonging to other users by modifying the invoice_id path parameter. The exposed data includes customer billing details and invoice history. Exploitation requires no special privileges beyond a standard account and can be reproduced with a single modified API request. This breaks tenant isolation and may expose sensitive business data.

This is more useful than a bare score.

How to Use CVSS in Reports

A practical report can include:

Severity: High
CVSS: 8.x / High
Rationale: <plain English explanation>

The rationale is critical because different organizations may use different CVSS versions, environmental adjustments, or internal risk frameworks.

If a client requires CVSS, follow their required version and scoring policy.

If the client does not require CVSS, still explain severity using the same thinking: reachability, privileges, user interaction, and impact.

References

CTA

KevinSec can help translate technical vulnerabilities into clear severity, business impact, and remediation priority. If your team receives scanner output but still struggles to decide what to fix first, a focused pentest report can turn findings into an actionable security roadmap.