CVSS v2 vs CVSS v3: A Practical Comparison for Vulnerability Scoring
Security teams rely on consistent scoring to prioritize fixes and communicate risk. The Common Vulnerability Scoring System (CVSS) provides a standardized framework to rate vulnerabilities. Over time, CVSS evolved from version 2 to version 3 in order to better reflect how risks play out in real environments. This article compares CVSS v2 and CVSS v3, highlights the main differences, explains the practical implications for assessment and triage, and offers guidance for migrating from CVSS v2 to CVSS v3.
What CVSS aims to measure
CVSS is designed to quantify the severity of a vulnerability in a way that is comparable across products and ecosystems. It comprises three metric groups: Base, Temporal, and Environmental. The Base Score captures the intrinsic characteristics of the vulnerability, the Temporal Score accounts for factors like exploit maturity, and the Environmental Score adjusts the score to reflect the importance of the affected asset in a specific environment. Both CVSS v2 and CVSS v3 use a Base Score as the core metric, but the definitions and formulas behind that score differ between versions, which can lead to different severity labels for the same flaw.
Key differences at a glance
CVSS v2 exposed the Access Vector with values such as Network, Adjacent Network, and Local. CVSS v3 reframed this as Attack Vector (Network, Adjacent Network, Local, Physical), expanding the realistic paths an attacker could use and assigning different weights to each path. Both versions include a measure of how difficult the exploit is, but the interaction with other metrics changes across versions. CVSS v3 tends to produce different final scores when complexity interacts with new metrics like Privileges Required and User Interaction. CVSS v2 used Authentication as a separate metric, indicating how many credentials or attempts an attacker would need. CVSS v3 replaces that with Privileges Required, along with its own qualitative levels (None, Low, High), changing how a vulnerability’s access requirements are interpreted. A new metric in CVSS v3 that represents whether exploitation requires the user to perform an action. This factor can reduce or increase the final score depending on whether user participation is necessary. In v2, Impact was a single combination of Confidentiality, Integrity, and Availability. CVSS v3 separates these into distinct metrics (Confidentiality Impact, Integrity Impact, Availability Impact) and uses a different calculation depending on Scope, which often leads to different final scores for the same flaw. Both versions supportTemporal and Environmental scores, but the way these are combined with the Base Score and the values used for each metric are updated in CVSS v3 to better reflect modern security settings and asset importance.
How the base score is computed in v2 vs v3 (conceptual view)
The Base Score is the heart of CVSS. In CVSS v2, it combines Exploitability (which depends on Attack Vector, Attack Complexity, and Authentication) with Impact (which depends on Confidentiality, Integrity, and Availability), producing a single score on a 0-10 scale. The formula emphasizes how easily an attacker can exploit a vulnerability and how badly it damages assets.
In CVSS v3, the Base Score also blends Exploitability and Impact, but with a revised model. Scope plays a crucial role: if exploitation affects beyond the originally vulnerable component, the calculation shifts, often increasing the final score. Privileges Required and User Interaction introduce new dimensions for assessing how much privilege or user action is needed to exploit the flaw. The result is a more nuanced score that often aligns better with real-world risk, especially in multi-component systems and modern software stacks.
Mapping between CVSS v2 and CVSS v3
When organizations migrate from CVSS v2 to CVSS v3, it helps to think in terms of metric mappings, even though the exact formulas differ. Here are common correspondences to guide a practical translation:
- Access Vector (v2) → Attack Vector (v3): Network, Adjacent Network, Local map to the same paths, with an expanded Physical option in v3.
- Access Complexity (v2) → Attack Complexity (v3): Both assess how hard it is to exploit; values align conceptually but weights differ in the new formula.
- Authentication (v2) → Privileges Required (v3): Authentication indicates credential requirements; Privileges Required assesses the attacker’s required privileges to exploit the vulnerability.
- Confidentiality/Integrity/Availability Impact (v2) → Confidentiality Impact / Integrity Impact / Availability Impact (v3): These metrics exist in both versions, but v3 uses a redesigned calculation that interacts with Scope.
- Remediation and environmental context (v2) → Environmental and Temporal metrics (v3): The same practical idea exists, but the names and emphasis shift to reflect current environments and exploit trends.
Migration requires careful data mapping and sometimes re-scoring because the same vulnerability can receive a different Base Score and severity in CVSS v3. This makes the upgrade worthwhile for consistent risk communication, but it also requires discipline in updating tooling and training teams.
Why CVSS v3 matters for modern security programs
By explicitly modeling scope and including a user-interaction dimension, CVSS v3 better mirrors how modern attacks unfold in complex environments. The revised scoring often changes the priority of fixes. A flaw that previously appeared low risk may rise if it can impact multiple components or if user interaction is not required in a given context. Clear distinctions between the needs of high-value targets and ordinary systems help security teams explain risk to developers and management more effectively. The updated taxonomy reduces ambiguity in labeling severity and supports more uniform security postures across teams and vendors.
Practical considerations for migrating from CVSS v2 to CVSS v3
Start by inventorying all vulnerabilities currently scored with CVSS v2 in your systems. Identify where the two versions diverge in risk interpretation. Create a mapping strategy from v2 metrics to v3. Treat AV/AC/AUTH as starting points, then adjust for Privileges Required and User Interaction in v3’s framework. Re-score critical vulnerabilities using CVSS v3, and compare the results with historical data to understand shifts in severity and prioritization. Ensure scanners, ticketing systems, and dashboards can store and display CVSS v3 data. Update workflows to reference the v3 semantics, especially Scope and Privileges Required. Provide training for security analysts, developers, and risk managers on the new definitions, scoring patterns, and interpretation of the CVSS v3 metrics. When reporting to stakeholders, explain why scores changed due to version upgrade, and how this affects remediation timelines and risk appetite.
Practical examples
Example 1: A vulnerability with Network access, Low Attack Complexity, No User Interaction, and No Privileges Required in CVSS v2 would likely produce a higher severity when migrated to CVSS v3 if, under the new framework, the attack path becomes broader or the impact is realized across multiple components. In CVSS v3, even with Network access, the addition of a scope consideration and user-interaction analysis could shift the Base Score beyond the former threshold, altering prioritization decisions.
Example 2: A local privilege escalation that requires Local access, High Privilege required, and No User Interaction in CVSS v2 may still be severe in CVSS v3, but the focus on Privileges Required and the potential for scope changes can change the final severity. The same flaw could become more or less critical depending on whether exploitation touches other assets beyond the immediate vulnerable component.
Conclusion
CVSS v3 represents a thoughtful advancement over CVSS v2, aiming to align scoring with contemporary attack patterns and enterprise architectures. The introduction of Scope, Privileges Required, and User Interaction, along with a rebalanced approach to Impact, yields scores that tend to reflect real-world risk more closely. For organizations, the move from CVSS v2 to CVSS v3 is a practical step toward better risk communication, improved prioritization, and more consistent vulnerability management. By planning a careful migration—mapping metrics, re-scoring critical items, updating tooling, and training teams—you can achieve a clearer view of risk and a smoother path to remediation.
