CVSS v2 Calculator
The CVSS v2 calculator scores a vulnerability with the CVSS version 2.0 equations from the FIRST guide. Impact = 10.41 × (1 − (1 − ConfImpact) × (1 − IntegImpact) × (1 − AvailImpact)); Exploitability = 20 × AccessVector × AccessComplexity × Authentication; and BaseScore = round_to_1_decimal(((0.6 × Impact) + (0.4 × Exploitability) − 1.5) × f(Impact)), where f(Impact) is 0 if Impact is 0 and 1.176 otherwise.
Temporal and Environmental scores follow the guide's equations and its three worked examples. v2.0 vectors have no CVSS: prefix and use ND for a Temporal or Environmental metric that is not used. FIRST's guide defines no qualitative rating; the Low, Medium and High labels shown here are the NVD convention.
CVSS v2.0 score 7.5, High, CVSS-B
Low / Medium / High is the National Vulnerability Database convention (0.0–3.9, 4.0–6.9, 7.0–10.0). FIRST's CVSS v2.0 guide defines no severity bands.
- Base
- 7.5
Load a worked example
A vulnerability exploitable with network access means the vulnerable software is bound to the network stack and the attacker does not require local…
Specialized access conditions or extenuating circumstances do not exist.
Authentication is not required to exploit the vulnerability.
There is considerable informational disclosure.
Modification of some system files or information is possible, but the attacker does not have control over what can be modified, or the scope of what…
There is reduced performance or interruptions in resource availability.
Assigning this value to the metric will not influence the score.
Assigning this value to the metric will not influence the score.
Assigning this value to the metric will not influence the score.
Assigning this value to the metric will not influence the score.
Assigning this value to the metric will not influence the score.
Assigning this value to the metric will not influence the score.
Assigning this value to the metric will not influence the score.
Assigning this value to the metric will not influence the score.
How this score was computed
Result
- Score to publish
7.5 (CVSS-B)Base score.
Base score
- Impact
10.41 × (1 − (1 − ConfImpact) × (1 − IntegImpact) × (1 − AvailImpact))10.41 × (1 − (1 − 0.275) × (1 − 0.275) × (1 − 0.275)) = 6.443 - Exploitability
20 × AccessVector × AccessComplexity × Authentication20 × 1 × 0.71 × 0.704 = 9.9968 - f(Impact)
0 if Impact = 0, otherwise 1.1761.176 - Base score
round_to_1_decimal(((0.6 × Impact) + (0.4 × Exploitability) − 1.5) × f(Impact))round((0.6 × 6.443 + 0.4 × 9.9968 − 1.5) × 1.176) = round(7.4847) = 7.5
Scoring runs in your browser; nothing you enter is uploaded. Independent implementation of the FIRST.org CVSS v2.0 specification; CVSS is owned by FIRST.org, Inc. Severity labels for v2.0 follow the NVD convention. (Low 0.0–3.9, Medium 4.0–6.9, High 7.0–10.0)
TL;DRWhat this calculator does
4 points
- Metrics: Access Vector, Access Complexity, Authentication and the three impacts (None, Partial, Complete); Temporal E, RL, RC; Environmental CDP, TD, CR, IR, AR.
- No qualitative scale in the FIRST guide. NVD labels v2.0 scores Low 0.0 to 3.9, Medium 4.0 to 6.9, High 7.0 to 10.0.
- A v2.0 vector has no prefix: AV:N/AC:L/Au:N/C:P/I:P/A:P.
- Scores are rounded to one decimal place with round_to_1_decimal.
CVSS v2 equations
From section 3.2 of the FIRST CVSS v2.0 guide:
BaseScore = round_to_1_decimal(((0.6 × Impact) + (0.4 × Exploitability) − 1.5) × f(Impact))Impact = 10.41 × (1 − (1 − ConfImpact) × (1 − IntegImpact) × (1 − AvailImpact))Exploitability = 20 × AccessVector × AccessComplexity × Authenticationf(Impact) = 0 if Impact = 0, otherwise 1.176TemporalScore = round_to_1_decimal(BaseScore × Exploitability × RemediationLevel × ReportConfidence)EnvironmentalScore = round_to_1_decimal((AdjustedTemporal + (10 − AdjustedTemporal) × CollateralDamagePotential) × TargetDistribution)AdjustedImpact = min(10, 10.41 × (1 − (1 − ConfImpact × ConfReq) × (1 − IntegImpact × IntegReq) × (1 − AvailImpact × AvailReq)))AdjustedTemporal is the Temporal score recomputed with the Base equation using AdjustedImpact. Weights used:
| Metric | Weights |
|---|---|
| Access Vector | Local 0.395, Adjacent Network 0.646, Network 1 |
| Access Complexity | High 0.35, Medium 0.61, Low 0.71 |
| Authentication | Multiple 0.45, Single 0.56, None 0.704 |
| Confidentiality / Integrity / Availability Impact | None 0, Partial 0.275, Complete 0.66 |
| Exploitability (E) | Unproven 0.85, Proof-of-Concept 0.9, Functional 0.95, High 1, Not Defined 1 |
| Remediation Level (RL) | Official Fix 0.87, Temporary Fix 0.9, Workaround 0.95, Unavailable 1, Not Defined 1 |
| Report Confidence (RC) | Unconfirmed 0.9, Uncorroborated 0.95, Confirmed 1, Not Defined 1 |
| Collateral Damage Potential (CDP) | None 0, Low 0.1, Low-Medium 0.3, Medium-High 0.4, High 0.5, Not Defined 0 |
| Target Distribution (TD) | None 0, Low 0.25, Medium 0.75, High 1, Not Defined 1 |
| Security Requirements (CR, IR, AR) | Low 0.5, Medium 1, High 1.51, Not Defined 1 |
CVSS 2.0 metrics explained
Descriptions are excerpted from the A Complete Guide to the Common Vulnerability Scoring System Version 2.0. Each metric has a vector abbreviation (in brackets) that appears in the vector string.
Base metrics · 6 metrics
Fundamental characteristics of the vulnerability that stay constant over time and across environments.
Access Vector (AV)
This metric reflects how the vulnerability is exploited.
- Local (AV:L) — A vulnerability exploitable with only local access requires the attacker to have either physical access to the vulnerable system or a local (shell) account. Examples of locally exploitable vulnerabilities are peripheral attacks such as Firewire/USB DMA attacks, and local privilege escalations (e.g., sudo).
- Adjacent Network (AV:A) — A vulnerability exploitable with adjacent network access requires the attacker to have access to either the broadcast or collision domain of the vulnerable software. Examples of local networks include local IP subnet, Bluetooth, IEEE 802.11, and local Ethernet segment.
- Network (AV:N) — A vulnerability exploitable with network access means the vulnerable software is bound to the network stack and the attacker does not require local network access or local access. Such a vulnerability is often termed "remotely exploitable". An example of a network attack is an RPC buffer overflow.
Access Complexity (AC)
This metric measures the complexity of the attack required to exploit the vulnerability once an attacker has gained access to the target system. For example, consider a buffer overflow in an Internet service: once the target system is located, the attacker can launch an exploit at will.
- High (AC:H) — Specialized access conditions exist. For example: - In most configurations, the attacking party must already have elevated privileges or spoof additional systems in addition to the attacking system (e.g., DNS hijacking). - The attack depends on social engineering methods that would be easily detected by knowledgeable people. For example, the victim must perform several suspicious or atypical actions. - The vulnerable configuration is seen very rarely in practice.
- Medium (AC:M) — The access conditions are somewhat specialized; the following are examples: - The attacking party is limited to a group of systems or users at some level of authorization, possibly untrusted. - Some information must be gathered before a successful attack can be launched. - The affected configuration is non-default, and is not commonly configured (e.g., a vulnerability present when a server performs user account authentication via a specific scheme, but not present for another authentication scheme).
- Low (AC:L) — Specialized access conditions or extenuating circumstances do not exist. The following are examples: - The affected product typically requires access to a wide range of systems and users, possibly anonymous and untrusted (e.g., Internet-facing web or mail server). - The affected configuration is default or ubiquitous. - The attack can be performed manually and requires little skill or additional information gathering. - The race condition is a lazy one (i.e., it is technically a race but easily winnable).
Authentication (Au)
This metric measures the number of times an attacker must authenticate to a target in order to exploit a vulnerability. This metric does not gauge the strength or complexity of the authentication process, only that an attacker is required to provide credentials before an exploit may occur.
- Multiple (Au:M) — Exploiting the vulnerability requires that the attacker authenticate two or more times, even if the same credentials are used each time. An example is an attacker authenticating to an operating system in addition to providing credentials to access an application hosted on that system.
- Single (Au:S) — The vulnerability requires an attacker to be logged into the system (such as at a command line or via a desktop session or web interface).
- None (Au:N) — Authentication is not required to exploit the vulnerability.
Confidentiality Impact (C)
This metric measures the impact on confidentiality of a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
- None (C:N) — There is no impact to the confidentiality of the system.
- Partial (C:P) — There is considerable informational disclosure. Access to some system files is possible, but the attacker does not have control over what is obtained, or the scope of the loss is constrained. An example is a vulnerability that divulges only certain tables in a database.
- Complete (C:C) — There is total information disclosure, resulting in all system files being revealed. The attacker is able to read all of the system's data (memory, files, etc.)
Integrity Impact (I)
This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and guaranteed veracity of information.
- None (I:N) — There is no impact to the integrity of the system.
- Partial (I:P) — Modification of some system files or information is possible, but the attacker does not have control over what can be modified, or the scope of what the attacker can affect is limited. For example, system or application files may be overwritten or modified, but either the attacker has no control over which files are affected or the attacker can modify files within only a limited context or scope.
- Complete (I:C) — There is a total compromise of system integrity. There is a complete loss of system protection, resulting in the entire system being compromised. The attacker is able to modify any files on the target system.
Availability Impact (A)
This metric measures the impact to availability of a successfully exploited vulnerability. Availability refers to the accessibility of information resources. Attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
- None (A:N) — There is no impact to the availability of the system.
- Partial (A:P) — There is reduced performance or interruptions in resource availability. An example is a network-based flood attack that permits a limited number of successful connections to an Internet service.
- Complete (A:C) — There is a total shutdown of the affected resource. The attacker can render the resource completely unavailable.
Temporal metrics · 3 metrics
Characteristics that change over time: exploit availability, remediation status and report confidence. Optional; Not Defined skips the metric.
Exploitability (E)
This metric measures the current state of exploit techniques or code availability. Public availability of easy-to-use exploit code increases the number of potential attackers by including those who are unskilled, thereby increasing the severity of the vulnerability.
- Unproven (E:U) — No exploit code is available, or an exploit is entirely theoretical.
- Proof-of-Concept (E:POC) — Proof-of-concept exploit code or an attack demonstration that is not practical for most systems is available. The code or technique is not functional in all situations and may require substantial modification by a skilled attacker.
- Functional (E:F) — Functional exploit code is available. The code works in most situations where the vulnerability exists.
- High (E:H) — Either the vulnerability is exploitable by functional mobile autonomous code, or no exploit is required (manual trigger) and details are widely available. The code works in every situation, or is actively being delivered via a mobile autonomous agent (such as a worm or virus).
- Not Defined (E:ND) — Assigning this value to the metric will not influence the score. It is a signal to the equation to skip this metric.
Remediation Level (RL)
The remediation level of a vulnerability is an important factor for prioritization. The typical vulnerability is unpatched when initially published. Workarounds or hotfixes may offer interim remediation until an official patch or upgrade is issued.
- Official Fix (RL:OF) — A complete vendor solution is available. Either the vendor has issued an official patch, or an upgrade is available.
- Temporary Fix (RL:TF) — There is an official but temporary fix available. This includes instances where the vendor issues a temporary hotfix, tool, or workaround.
- Workaround (RL:W) — There is an unofficial, non-vendor solution available. In some cases, users of the affected technology will create a patch of their own or provide steps to work around or otherwise mitigate the vulnerability.
- Unavailable (RL:U) — There is either no solution available or it is impossible to apply.
- Not Defined (RL:ND) — Assigning this value to the metric will not influence the score. It is a signal to the equation to skip this metric.
Report Confidence (RC)
This metric measures the degree of confidence in the existence of the vulnerability and the credibility of the known technical details. Sometimes, only the existence of vulnerabilities are publicized, but without specific details. The vulnerability may later be corroborated and then confirmed through acknowledgement by the author or vendor of the affected technology.
- Unconfirmed (RC:UC) — There is a single unconfirmed source or possibly multiple conflicting reports. There is little confidence in the validity of the reports. An example is a rumor that surfaces from the hacker underground.
- Uncorroborated (RC:UR) — There are multiple non-official sources, possibly including independent security companies or research organizations. At this point there may be conflicting technical details or some other lingering ambiguity.
- Confirmed (RC:C) — The vulnerability has been acknowledged by the vendor or author of the affected technology. The vulnerability may also be Confirmed when its existence is confirmed from an external event such as publication of functional or proof-of-concept exploit code or widespread exploitation.
- Not Defined (RC:ND) — Assigning this value to the metric will not influence the score. It is a signal to the equation to skip this metric.
Environmental metrics · 5 metrics
Characteristics tied to your IT environment: collateral damage, how many systems are affected and how much each security property matters. Optional; Not Defined skips the metric.
Collateral Damage Potential (CDP)
This metric measures the potential for loss of life or physical assets through damage or theft of property or equipment. The metric may also measure economic loss of productivity or revenue.
- None (CDP:N) — There is no potential for loss of life, physical assets, productivity or revenue.
- Low (CDP:L) — A successful exploit of this vulnerability may result in slight physical or property damage. Or, there may be a slight loss of revenue or productivity to the organization.
- Low-Medium (CDP:LM) — A successful exploit of this vulnerability may result in moderate physical or property damage. Or, there may be a moderate loss of revenue or productivity to the organization.
- Medium-High (CDP:MH) — A successful exploit of this vulnerability may result in significant physical or property damage or loss. Or, there may be a significant loss of revenue or productivity.
- High (CDP:H) — A successful exploit of this vulnerability may result in catastrophic physical or property damage and loss. Or, there may be a catastrophic loss of revenue or productivity.
- Not Defined (CDP:ND) — Assigning this value to the metric will not influence the score. It is a signal to the equation to skip this metric.
Target Distribution (TD)
This metric measures the proportion of vulnerable systems. It is meant as an environment-specific indicator in order to approximate the percentage of systems that could be affected by the vulnerability.
- None (TD:N) — No target systems exist, or targets are so highly specialized that they only exist in a laboratory setting. Effectively 0% of the environment is at risk.
- Low (TD:L) — Targets exist inside the environment, but on a small scale. Between 1% - 25% of the total environment is at risk.
- Medium (TD:M) — Targets exist inside the environment, but on a medium scale. Between 26% - 75% of the total environment is at risk.
- High (TD:H) — Targets exist inside the environment on a considerable scale. Between 76% - 100% of the total environment is considered at risk.
- Not Defined (TD:ND) — Assigning this value to the metric will not influence the score. It is a signal to the equation to skip this metric.
Confidentiality Requirement (CR)
These metrics enable the analyst to customize the CVSS score depending on the importance of the affected IT asset to a user’s organization, measured in terms of confidentiality, integrity, and availability.
- Low (CR:L) — Loss of confidentiality is likely to have only a limited adverse effect on the organization or individuals associated with the organization (e.g., employees, customers).
- Medium (CR:M) — Loss of confidentiality is likely to have a serious adverse effect on the organization or individuals associated with the organization (e.g., employees, customers).
- High (CR:H) — Loss of confidentiality is likely to have a catastrophic adverse effect on the organization or individuals associated with the organization (e.g., employees, customers).
- Not Defined (CR:ND) — Assigning this value to the metric will not influence the score. It is a signal to the equation to skip this metric.
Integrity Requirement (IR)
These metrics enable the analyst to customize the CVSS score depending on the importance of the affected IT asset to a user’s organization, measured in terms of confidentiality, integrity, and availability.
- Low (IR:L) — Loss of integrity is likely to have only a limited adverse effect on the organization or individuals associated with the organization (e.g., employees, customers).
- Medium (IR:M) — Loss of integrity is likely to have a serious adverse effect on the organization or individuals associated with the organization (e.g., employees, customers).
- High (IR:H) — Loss of integrity is likely to have a catastrophic adverse effect on the organization or individuals associated with the organization (e.g., employees, customers).
- Not Defined (IR:ND) — Assigning this value to the metric will not influence the score. It is a signal to the equation to skip this metric.
Availability Requirement (AR)
These metrics enable the analyst to customize the CVSS score depending on the importance of the affected IT asset to a user’s organization, measured in terms of confidentiality, integrity, and availability.
- Low (AR:L) — Loss of availability is likely to have only a limited adverse effect on the organization or individuals associated with the organization (e.g., employees, customers).
- Medium (AR:M) — Loss of availability is likely to have a serious adverse effect on the organization or individuals associated with the organization (e.g., employees, customers).
- High (AR:H) — Loss of availability is likely to have a catastrophic adverse effect on the organization or individuals associated with the organization (e.g., employees, customers).
- Not Defined (AR:ND) — Assigning this value to the metric will not influence the score. It is a signal to the equation to skip this metric.
CVSS v2 severity ratings
FIRST's CVSS v2.0 guide defines no qualitative severity bands. The National Vulnerability Database (NVD) labels v2.0 scores as follows; this calculator uses the same convention and says so next to every result.
| NVD rating (v2.0) | Score range |
|---|---|
| Low | 0.0 – 3.9 |
| Medium | 4.0 – 6.9 |
| High | 7.0 – 10.0 |
Source: NVD, Vulnerability Metrics.
Worked CVSS 2.0 examples
Use “Load a worked example” in the calculator to open any of these. Scores are computed live by the same engine.
AV:N/AC:L/Au:N/C:C/I:C/A:CThe v2.0 maximum.
Source: FIRST CVSS v3.1 User Guide examples (v2.0 scores).
Open in the calculatorAV:N/AC:L/Au:N/C:P/I:P/A:PA common NVD v2 base vector.
Source: FIRST CVSS v3.1 User Guide examples (v2.0 scores).
Open in the calculatorAV:N/AC:M/Au:N/C:N/I:P/A:NMedium access complexity (some social engineering), partial integrity impact.
Source: FIRST CVSS v3.1 User Guide examples (v2.0 scores).
Open in the calculatorAV:N/AC:L/Au:N/C:N/I:N/A:C/E:F/RL:OF/RC:CBase 7.8; functional exploit, official fix, confirmed: Temporal 6.4.
Source: FIRST CVSS v2.0 guide, section 3.3.1.
Open in the calculatorFrequently asked questions
What is the CVSS v2 calculator and how is the score computed?
It implements the CVSS 2.0 equations from the FIRST guide. Impact = 10.41 × (1 − (1 − C) × (1 − I) × (1 − A)) using 0, 0.275 and 0.660 for None, Partial and Complete. Exploitability = 20 × AccessVector × AccessComplexity × Authentication. BaseScore = round_to_1_decimal(((0.6 × Impact) + (0.4 × Exploitability) − 1.5) × f(Impact)). The Temporal score multiplies the Base score by Exploitability, Remediation Level and Report Confidence weights.
What severity does a CVSS v2 score have?
FIRST's v2.0 guide does not define qualitative severity bands. The National Vulnerability Database uses its own convention for v2.0 scores: Low 0.0 to 3.9, Medium 4.0 to 6.9 and High 7.0 to 10.0. There is no Critical rating for v2.0 in that convention, so a v2.0 score of 10.0 is High.
How do I write a CVSS v2 vector string?
Without a CVSS: prefix: AV:[L,A,N]/AC:[H,M,L]/Au:[M,S,N]/C:[N,P,C]/I:[N,P,C]/A:[N,P,C], for example AV:N/AC:L/Au:N/C:P/I:P/A:P. Temporal metrics are E:[U,POC,F,H,ND]/RL:[OF,TF,W,U,ND]/RC:[UC,UR,C,ND] and Environmental metrics are CDP:[N,L,LM,MH,H,ND]/TD:[N,L,M,H,ND]/CR, IR and AR each [L,M,H,ND]. A metric that is not used is written ND.
How does the v2 Environmental score work?
The guide recomputes the Temporal score with an AdjustedImpact that weights each impact by its Security Requirement (Low 0.5, Medium 1.0, High 1.51), then applies EnvironmentalScore = round_to_1_decimal((AdjustedTemporal + (10 − AdjustedTemporal) × CollateralDamagePotential) × TargetDistribution). Not Defined Collateral Damage Potential counts as 0 and Not Defined Target Distribution counts as 1.0.
Is CVSS v2 still used?
Older vulnerability records carry v2.0 vectors, and the National Vulnerability Database keeps calculators for it. For new assessments use the version your process requires; v3.1 and v4.0 are the later versions.
Sources and official calculators
Official calculators: NVD CVSS v2 calculator · NVD CVSS severity ranges
CVSS is a trademark of FIRST.org, Inc. This calculator is an independent implementation of the published specifications and is not affiliated with FIRST or NIST. Specification text and examples were read on 3 November 2026.