- CVSS v4.0 Calculator: What Changed for Pentest Teams
- Who should read this (and who can skip it)
- What changed from CVSS v3.1 to v4.0
- The mixed-version problem
- Keeping scores consistent across your team
- Updating your report templates
- Building team knowledge that compounds
- A worked example: rescoring a web app finding
- What to do next
- Related content
- Frequently asked questions
CVSS v4.0 Calculator: What Changed for Pentest Teams
If your team runs Nessus on Monday and does manual web app testing on Thursday, your report might now contain CVSS v3.1 scores from the scanner and CVSS v4.0 scores from your testers. The numbers use different formulas and are not directly comparable. And your client's remediation team is prioritizing fixes based on those numbers.
CVSS v4.0, published by FIRST (Forum of Incident Response and Security Teams) on November 1, 2023, restructured the metric system. Scope is gone. A new metric (Attack Requirements) splits a concept that v3.1 conflated. User Interaction has three values instead of two. The vector string format is different enough that pasting a v4.0 vector into a v3.1 template field will produce silently wrong output.
This guide walks through what changed, why it matters for pentest reports specifically, and how to keep scoring consistent across your team during the migration.
Key Takeaways
- CVSS v4.0 replaced the Base / Temporal / Environmental structure with Base / Supplemental / Environmental / Threat, changing how scores are calculated and reported.
- The Scope metric from v3.1 is gone, replaced by separate Vulnerable System (VC, VI, VA) and Subsequent System (SC, SI, SA) impact tracks that resolve edge cases where Scope was applied inconsistently.
- A new Attack Requirements (AT) metric separates deployment prerequisites from technical exploitation difficulty, which v3.1's Attack Complexity conflated into one value.
- Most vulnerability scanners (Nessus, Qualys, Nexpose, OpenVAS) still report CVSS v2 or v3.1 scores as of mid-2026, creating mixed-version reports when testers score manual findings in v4.0.
- Supplemental metrics (Safety, Automatable, Recovery, Value Density, Vulnerability Response Effort, Provider Urgency) are informational only and do not change the 0.0-10.0 base score.
- A shared CVSS calculator that stores scores per-issue, such as the one built into Dradis, prevents version drift between testers by making the scoring decision visible and consistent across the project.
Who should read this (and who can skip it)
This applies if:
- Your team has more than one person scoring findings, and you have seen inconsistent CVSS versions across the same report
- Your client has started asking why some findings show v3.1 scores and others show v4.0
- You are updating report templates and need to know which fields change
- You use scanner imports alongside manual findings and need a consistent scoring standard
Skip this if:
- You work solo and already understand the v4.0 metric changes
- Your clients contractually require CVSS v3.1 (common in Payment Card Industry (PCI) engagements) and you have no plans to migrate
What changed from CVSS v3.1 to v4.0
Scope is gone
CVSS v3.1 had a single Scope metric with two values: Changed and Unchanged. It attempted to capture whether a vulnerability could affect systems beyond the component being attacked. In practice, Scope was applied inconsistently. A tester scoring a reflected Cross-Site Scripting (XSS) would debate whether the victim's browser session constituted a "scope change" from the web application. Two experienced testers could reasonably disagree, producing different scores for the same finding.
v4.0 removes Scope and replaces it with two parallel impact tracks:
- Vulnerable System impact (VC, VI, VA): the confidentiality, integrity, and availability impact on the component being attacked
- Subsequent System impact (SC, SI, SA): the impact on systems beyond the vulnerable component
This is more precise. Instead of a binary "did scope change?" question, the tester evaluates impact on each system independently. For the XSS example: the vulnerable system (the web application) has a confidentiality impact, and the subsequent system (the user's browser session or downstream services) has a separate, independently evaluated impact.
Attack Requirements is new
v3.1's Attack Complexity (AC) tried to capture two different concepts in one metric: how technically difficult the exploit is, and whether specific environmental conditions must exist for exploitation.
v4.0 separates them:
- Attack Complexity (AC): the technical difficulty of exploitation itself. Low or High.
- Attack Requirements (AT): whether specific deployment or configuration conditions must be true for exploitation. None or Present.
A SQL injection that requires a specific Web Application Firewall (WAF) bypass technique is AC:H (technically complex) but AT:N (no special deployment conditions required). A race condition that only triggers under specific server threading configurations is AC:L (technically straightforward once conditions exist) but AT:P (requires specific deployment conditions).
Many findings that were AC:H in v3.1 may now be AC:L/AT:P or AC:L/AT:N in v4.0. The scores will differ. If your report template still uses the v3.1 AC field without the new AT field, those scores are incomplete.
User Interaction has three values
v3.1 had two values: Required and None.
v4.0 has three:
| Value | Meaning | Example |
|---|---|---|
| None (N) | No user interaction needed | Remote code execution via network service |
| Passive (P) | Victim only needs to browse or open content | Drive-by download, malicious ad rendering |
| Active (A) | Victim must take specific action | Click a phishing link, open a crafted file |
This changes scores for many web application findings. A stored XSS that fires when any user visits the page is UI:P (passive). A reflected XSS requiring the victim to click a crafted URL is UI:A (active). In v3.1, both were UI:R. In v4.0, they get different scores.
Temporal became Threat, and got simpler
v3.1 had three Temporal metrics: Exploit Code Maturity, Remediation Level, and Report Confidence. In practice, teams rarely filled in Remediation Level or Report Confidence accurately, leaving both at "Not Defined" (the default). The Temporal score added nothing.
v4.0 renamed the group to Threat and kept only Exploit Maturity (E). Remediation Level and Report Confidence were dropped. This simplifies the scoring workflow without losing meaningful signal.
Supplemental metrics are informational only
v4.0 introduced six Supplemental metrics: Safety (S), Automatable (AU), Recovery (R), Value Density (V), Vulnerability Response Effort (RE), and Provider Urgency (U). These provide context but do not change the 0.0-10.0 base score.
For pentest reports, include them when your client's remediation team needs prioritization context. They are optional and should match what your client expects.
The vector string format is different
A CVSS v4.0 vector starts with CVSS:4.0/ and uses different metric abbreviations:
v3.1: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N
v4.0: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:N/SC:L/SI:L/SA:N
The metrics, values, and formula are all different. A v4.0 vector pasted into a v3.1 field will appear to work, but every parsed value will be wrong. This is the silent corruption problem: the report looks normal, but the scores are built on mismatched data.
The mixed-version problem
As of mid-2026, most vulnerability scanners still do not output CVSS v4.0:
- Nessus: CVSS v2 and v3.1 only.
- Qualys: CVSS v2 and v3.1 only.
- Nexpose / InsightVM: CVSS v2 and v3.1 only.
- OpenVAS: CVSS v2 and v3.0/v3.1 only.
The NVD (National Vulnerability Database) is adding v4.0 scores to new CVEs (Common Vulnerabilities and Exposures), but coverage of older CVEs is incomplete.
The result for a typical pentest engagement: scanner-imported findings arrive with v3.1 scores. Manually scored web application findings (XSS, IDOR, business logic flaws) use v4.0 if the tester is current. The report contains both versions. The client's remediation team sees a Critical (9.8) v3.1 finding next to a Critical (9.3) v4.0 finding and wonders why the numbers differ for what seems like comparable severity.
Three approaches:
1. Standardize on v4.0 for manual findings, document the version per finding. This is the most honest approach. Include a note in the report methodology section stating which findings use which CVSS version and why. The reader knows what they are looking at.
2. Rescore everything in one version. More work, but eliminates mixed-version confusion. If you rescore scanner findings in v4.0, document the original scanner score alongside your v4.0 score so the client can cross-reference with their vulnerability management tool.
3. Standardize on v3.1 until scanners catch up. Pragmatic for teams with PCI-adjacent clients where CVSS thresholds are contractually defined in v3.1 terms. Not wrong, but the migration window is closing. At some point the team needs to switch, and the longer you wait, the larger the template and process change.
Keeping scores consistent across your team
The version migration makes scoring drift worse. Two testers, same finding type, different CVSS scores. This was already a problem with v3.1's ambiguous Scope metric. During migration, the disagreement can be about the CVSS version itself, not just the values.
The structural fix is a shared calculator tied to a shared finding database. When the scoring decision happens inside the project tool rather than in each tester's head, the version and values are visible to the whole team.
Dradis ships with a built-in CVSS calculator that supports v3.0, v3.1, and v4.0. The calculator is a tab on each Issue: select the version, set the metrics, and the output writes to structured fields (CVSSv4.BaseVector, score, severity). When the report generates, those fields populate the template without copy-paste.
The version switching is per-issue. For a project where scanner imports bring in v3.1 data, the team can score manual findings in v4.0 and the report template renders both versions with their correct labels. For a project where the client requires v3.1, the team uses v3.1 throughout.
The calculator runs on the Dradis instance, not an external API. For regulated environments, the calculation happens on your server.
The Free CVSS v4.0 Calculator provides the same v4.0 calculation logic outside of the Dradis app. Useful for quick checks or sharing scores with clients.
Updating your report templates
If your report template references CVSS v3.1 fields, three things need updating:
1. Add the new fields. v4.0 vectors use different metric abbreviations. Your template needs fields for CVSSv4.BaseVector, CVSSv4.BaseScore, CVSSv4.BaseSeverity, and optionally the individual metric values (AV, AC, AT, PR, UI, VC, VI, VA, SC, SI, SA).
2. Update severity thresholds if hardcoded. If your template uses conditional severity thresholds (e.g., "show all findings with score >= 7.0 in the Critical section"), verify those ranges still match. The v4.0 formula can shift scores: a 7.5 in v3.1 might be 7.1 or 8.2 in v4.0.
3. Handle mixed-version display. If your template renders CVSS vectors inline, it needs to handle both CVSS:3.1/... and CVSS:4.0/... formats. In Dradis, the reporting engine can filter and display findings by CVSS version using the vector prefix, letting you create separate report sections for v3.1-sourced and v4.0-scored findings if the client prefers that layout.
Building team knowledge that compounds
The v4.0 migration is a one-time effort per finding type in your library. Once a senior tester scores "Insecure Direct Object Reference" (IDOR) in v4.0 with the correct AT, UI, and impact values, that scoring decision is captured in the Issue Library. Every tester on the team pulls from that same entry for every subsequent engagement.
The difference: "we migrated to v4.0" versus "we migrated and every future engagement benefits from that work." In a shared library, the migration effort compounds. In individual spreadsheets, every tester migrates independently, and scoring drift returns within a quarter.
The Issue Library also handles the case where a finding's CVSS score changes based on new information. If FIRST releases a v4.0.1 revision or your team refines a scoring decision after a client dispute, the update happens in one place and flows to every future engagement. Revision history tracks why the score changed and who changed it.
A worked example: rescoring a web app finding
Take a common web application finding: Stored Cross-Site Scripting (XSS) in a user profile field, where any authenticated user viewing the profile triggers the payload.
CVSS v3.1 scoring:
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N
Score: 5.4 (Medium)
- AV:N (network access)
- AC:L (low complexity)
- PR:L (requires low privileges to inject the payload)
- UI:R (a user must view the page)
- S:C (scope changed, the victim's browser is impacted beyond the web application)
- C:L/I:L/A:N (low confidentiality and integrity impact)
CVSS v4.0 scoring for the same finding:
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:L/VA:N/SC:L/SI:L/SA:N
Score: 5.1 (Medium)
- AT:N (no special deployment conditions needed)
- UI:P (passive: the victim only needs to browse the page, not click a specific link)
- VC:N/VI:L/VA:N (vulnerable system: the web app itself has low integrity impact)
- SC:L/SI:L/SA:N (subsequent system: the victim's browser session has low confidentiality and integrity impact)
Both land at Medium, but v3.1 gives 5.4 and v4.0 gives 5.1. The delta is small here, but the reasoning path is different. The v4.0 score required evaluating impact on two systems separately and distinguishing passive from active user interaction. For other finding types, the delta can be larger.
The same finding, two versions, two different numbers. Your report needs to handle that without confusing the client.
What to do next
- Audit your Issue Library for CVSS versions. Identify entries still scored in v3.1 and prioritize the finding types your team uses most frequently for v4.0 migration.
- Score one common finding type in v4.0 using the FIRST calculator or the Dradis calculator and compare with the v3.1 score. Note the reasoning differences, not just the number.
- Update your report template to include v4.0 fields (
CVSSv4.BaseVector,CVSSv4.BaseScore,CVSSv4.BaseSeverity) alongside v3.1 fields so both versions render correctly. - Add a methodology note to your report template explaining which CVSS version applies to which findings and why the scores are not directly comparable.
- Set a team migration date. Waiting for scanners is a valid strategy, but document the decision so it is a choice, not inertia.
Related content
- Consistent Pentest Management: how Dradis solves scoring drift, template inconsistency, and collaboration overhead
- Free CVSS v4.0 Calculator: interactive scoring tool, no login required
- CVSS Calculator Support Guide: how to use the Dradis built-in calculator with CVSSv3.0, v3.1, and v4.0
- Risk Calculators: CVSSv4, DREAD, MITRE ATT&CK, and Custom: all available scoring systems in Dradis
- Issue Library: shared finding database with revision history, tags, and per-entry states
- Compounding Expertise in Pentest Teams: why a shared knowledge system gets smarter with every engagement
- FIRST CVSS v4.0 Specification Document: the authoritative source for all metric definitions
- FIRST CVSS v4.0 User Guide: practical guidance on scoring decisions and metric rationale
Frequently asked questions
Should my pentest team switch to CVSS v4.0 now?
It depends on your client base. If your clients reference CVSS thresholds contractually (common in PCI engagements where v3.1 thresholds are specified), you may need to continue using v3.1 for those engagements. For everything else, v4.0 is the current FIRST standard and produces more accurate scores for web application findings, particularly around user interaction and scope. The pragmatic approach is to migrate your Issue Library entries to v4.0 scoring and maintain v3.1 templates for clients that require them.
Do Nessus and other scanners support CVSS v4.0?
As of mid-2026, most commercial scanners (Nessus, Qualys, Nexpose, OpenVAS) still output CVSS v2 or v3.1 scores. The NVD is adding v4.0 scores to new CVEs but coverage of older entries is incomplete. This means scanner-imported findings in your pentest report will typically use v3.1 while manually scored findings may use v4.0, creating mixed-version reports that need version labeling.
Can I use CVSS v3.1 and v4.0 in the same report?
Yes, but document which version applies to each finding and why. Include a methodology note explaining that scanner-sourced findings use the scanner's native CVSS version (typically v3.1) while manually scored findings use v4.0. The scores are calculated with different formulas and are not directly comparable, so the reader needs to know which system produced each number.
What is the biggest scoring difference between v3.1 and v4.0?
The removal of Scope and its replacement with separate Vulnerable System and Subsequent System impact tracks. In v3.1, Scope:Changed inflated scores by a wide margin (a Medium finding could jump to High with S:C). In v4.0, the tester evaluates impact on each system independently, which produces more granular and often lower scores for findings that previously triggered a scope change. The new Attack Requirements metric also changes scores for findings that v3.1 classified as AC:H purely because of environmental prerequisites.
Does the Dradis CVSS calculator support v4.0?
Yes. The Dradis built-in calculator supports CVSS v3.0, v3.1, and v4.0. The calculator is a tab on each Issue in the project UI: select the version, set the metrics, and the output writes to structured fields (CVSSv4.BaseVector, score, severity) that populate your report template on export. The version can be set per-issue, so a project can contain both v3.1 scanner-imported scores and v4.0 manually scored findings. The Free CVSS v4.0 Calculator provides the same v4.0 logic outside of Dradis.
Mixed-version CVSS reports and scoring drift between testers are a shared-tool problem, not a training problem. Try Dradis Community Edition, free and open-source, with the built-in CVSS v4.0 calculator your team can use from day one.