Understand the CVSS vulnerability scoring system

Helm returns the Common Vulnerability Scoring System (CVSS) to provide numerical ratings corresponding to critical, high, medium, and low scores to ensure you understand your current vulnerability risk. Because older devices may only have a CVSS v2 score, while newer devices may only have a v3 score, Helm provides both CVSS v2 and v3 scores, enabling you to assess risk across the spectrum of your legacy and new devices.

This score incorporates a number of factors assessing the exploitability of a vulnerability.

Base score

For CVSS v3 scores, you can use a number of calculators to understand how the CVSS score for a particular vulnerability was calculated:

Hover over each metric classification value to get more information on how to determine which value applies to your situation. For your convenience, we've also provided those metric and value definitions below.

Rescore CVSS 3.x vulnerabilities

You can rescore all vulnerabilities associated with a particular product version or rescore individual vulnerabilities.

Base CVSS score

Every vulnerability in the NVD starts with a base CVSS score. You cannot modify this base score, but you can modify the temporal and environmental scores by assessing your particular device's situation. Every metric in these two sections is set to Not defined (X) by default, which has the highest impact on the CVSS score.

All definitions are extracted from first.org's CVSS 3.1 calculator.

How do I read a CVSS 3.1 vector string?

For CVSS 3.1, each section separated by a / in a vector string corresponds to one of the subcategories in the Base and Temporal categories. Thus, a string such as this:

CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:L/E:X/RL:O/RC:X

indicates that the Attack Vector is Network, Attack Complexity is High, Privileges Required is None, User Interaction is Required, Scope is Unchanged, and that the Confidentiality Impact is Low, Integrity Impact is Low, and Availability Impact is Low. It also indicates that Exploit Code Maturity is Not Defined, Remediation Level is Official fix, and Report Confidence is Not defined.

Exploitability metrics

Attack vector (AV)

This metric reflects the context by which vulnerability exploitation is possible. The Base Score increases the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable component.

Network (AV:N): The vulnerable component is bound to the network stack and the set of possible attackers extends beyond the other options listed, up to and including the entire Internet. Such a vulnerability is often termed 'remotely exploitable' and can be thought of as an attack being exploitable at the protocol level one or more network hops away (e.g., across one or more routers).
Adjacent (AV:A): The vulnerable component is bound to the network stack, but the attack is limited at the protocol level to a logically adjacent topology. This can mean an attack must be launched from the same shared physical (e.g., Bluetooth or IEEE 802.11) or logical (e.g., local IP subnet) network, or from within a secure or otherwise limited administrative domain (e.g., MPLS, secure VPN to an administrative network zone).
Local (AV:L): The vulnerable component is not bound to the network stack and the attacker’s path is via read/write/execute capabilities. Either: the attacker exploits the vulnerability by accessing the target system locally (e.g., keyboard, console), or remotely (e.g., SSH); or the attacker relies on User Interaction by another person to perform actions required to exploit the vulnerability (e.g., tricking a legitimate user into opening a malicious document).
Physical (AV:P): The attack requires the attacker to physically touch or manipulate the vulnerable component. Physical interaction may be brief or persistent.

Attack complexity (AC)

This metric describes the conditions beyond the attacker’s control that must exist in order to exploit the vulnerability. Such conditions may require the collection of more information about the target or computational exceptions. The assessment of this metric excludes any requirements for user interaction in order to exploit the vulnerability. If a specific configuration is required for an attack to succeed, the Base metrics should be scored assuming the vulnerable component is in that configuration.

Low (AC:L): Specialized access conditions or extenuating circumstances do not exist. An attacker can expect repeatable success against the vulnerable component.
High (AC:H): A successful attack depends on conditions beyond the attacker's control. That is, a successful attack cannot be accomplished at will, but requires the attacker to invest in some measurable amount of effort in preparation or execution against the vulnerable component before a successful attack can be expected. For example, a successful attack may require an attacker to: gather knowledge about the environment in which the vulnerable target/component exists; prepare the target environment to improve exploit reliability; or inject themselves into the logical network path between the target and the resource requested by the victim in order to read and/or modify network communications (e.g., a man in the middle attack).

Privileges required (PR)

This metric describes the level of privileges an attacker must possess before successfully exploiting the vulnerability.

None (PR:N): The attacker is unauthorized prior to attack, and therefore does not require any access to settings or files to carry out an attack.
Low (PR:L): The attacker is authorized with (i.e., requires) privileges that provide basic user capabilities that could normally affect only settings and files owned by a user. Alternatively, an attacker with Low privileges may have the ability to cause an impact only to non-sensitive resources.
High (PR:H): The attacker is authorized with (i.e., requires) privileges that provide significant (e.g., administrative) control over the vulnerable component that could affect component-wide settings and files.

User interaction (UI)

This metric captures the requirement for a user, other than the attacker, to participate in the successful compromise the vulnerable component. This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner.

None (UI:N): The vulnerable system can be exploited without any interaction from any user.
Required (UI:R): Successful exploitation of this vulnerability requires a user to take some action before the vulnerability can be exploited.

Scope (S)

Does a successful attack impact a component other than the vulnerable component? If so, the Base Score increases and the Confidentiality, Integrity and Authentication metrics should be scored relative to the impacted component.

Unchanged (S:U): An exploited vulnerability can only affect resources managed by the same security authority. In this case, the vulnerable component and the impacted component are either the same, or both are managed by the same security authority.
Changed (S:C): An exploited vulnerability can affect resources beyond the security scope managed by the security authority of the vulnerable component. In this case, the vulnerable component and the impacted component are different and managed by different security authorities.

Impact metrics

Confidentiality (C)

This metric measures the impact to the confidentiality of the information resources managed by a software component due to 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 loss of confidentiality within the impacted component.
Low (C:L): There is some loss of confidentiality. Access to some restricted information is obtained, but the attacker does not have control over what information is obtained, or the amount or kind of loss is limited. The information disclosure does not cause a direct, serious loss to the impacted component.
High (C:H): There is total loss of confidentiality, resulting in all resources within the impacted component being divulged to the attacker. Alternatively, access to only some restricted information is obtained, but the disclosed information presents a direct, serious impact.

Integrity (I)

This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information.

None (I:N): There is no loss of integrity within the impacted component.
Low (I:L): Modification of data is possible, but the attacker does not have control over the consequence of a modification, or the amount of modification is limited. The data modification does not have a direct, serious impact on the impacted component.
High (I:H): There is a total loss of integrity, or a complete loss of protection. For example, the attacker is able to modify any/all files protected by the impacted component. Alternatively, only some files can be modified, but malicious modification would present a direct, serious consequence to the impacted component.

Availability (A)

This metric measures the impact to the availability of the impacted component resulting from a successfully exploited vulnerability. It refers to the loss of availability of the impacted component itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of an impacted component.

None (A:N): There is no impact to availability within the impacted component.
Low (A:L): Performance is reduced or there are interruptions in resource availability. Even if repeated exploitation of the vulnerability is possible, the attacker does not have the ability to completely deny service to legitimate users. The resources in the impacted component are either partially available all of the time, or fully available only some of the time, but overall there is no direct, serious consequence to the impacted component.
High (A:H): There is total loss of availability, resulting in the attacker being able to fully deny access to resources in the impacted component; this loss is either sustained (while the attacker continues to deliver the attack) or persistent (the condition persists even after the attack has completed). Alternatively, the attacker has the ability to deny some availability, but the loss of availability presents a direct, serious consequence to the impacted component (e.g., the attacker cannot disrupt existing connections, but can prevent new connections; the attacker can repeatedly exploit a vulnerability that, in each instance of a successful attack, leaks a only small amount of memory, but after repeated exploitation causes a service to become completely unavailable).

CVSS 3.1: Temporal score

The Temporal metrics measure the current state of exploit techniques or code availability, the existence of any patches or workarounds, or the confidence that one has in the description of a vulnerability.

Exploit code maturity (E)

This metric measures the likelihood of the vulnerability being attacked, and is typically based on the current state of exploit techniques, exploit code availability, or active, 'in-the-wild' exploitation.

Not defined (E:X): This is the default setting. Assigning this value indicates there is insufficient information to choose one of the other values, and has no impact on the overall Temporal Score, i.e., it has the same effect on scoring as assigning High.
Unproven that exploit exists (E:U): No exploit code is available, or an exploit is theoretical.
Proof of concept code (E:P): Proof-of-concept exploit code is available, or an attack demonstration is not practical for most systems. The code or technique is not functional in all situations and may require substantial modification by a skilled attacker.
Functional exploit exists (E:F): Functional exploit code is available. The code works in most situations where the vulnerability exists.
High (E:H): Functional autonomous code exists, or no exploit is required (manual trigger) and details are widely available. Exploit code works in every situation, or is actively being delivered via an autonomous agent (such as a worm or virus). Network-connected systems are likely to encounter scanning or exploitation attempts. Exploit development has reached the level of reliable, widely-available, easy-to-use automated tools.

Remediation level (RL)

This metric 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. Each of these respective stages adjusts the temporal score downwards, reflecting the decreasing urgency as remediation becomes final.

Not defined (RL:X): This is the default setting. Assigning this value indicates there is insufficient information to choose one of the other values, and has no impact on the overall Temporal Score, i.e., it has the same effect on scoring as assigning Unavailable.
Official fix (RL:O): A complete vendor solution is available. Either the vendor has issued an official patch, or an upgrade is available.
Temporary fix (RL:T): 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.

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. For example, an impact may be recognized as undesirable, but the root cause may not be known. The vulnerability may later be corroborated by research which suggests where the vulnerability may lie, though the research may not be certain. Finally, a vulnerability may be confirmed through acknowledgement by the author or vendor of the affected technology. The urgency of a vulnerability is higher when a vulnerability is known to exist with certainty. This metric also suggests the level of technical knowledge available to would-be attackers.

Not defined (RC:X): Assigning this value indicates there is insufficient information to choose one of the other values, and has no impact on the overall Temporal Score, i.e., it has the same effect on scoring as assigning Confirmed.
Unknown (RC:U): There are reports of impacts that indicate a vulnerability is present. The reports indicate that the cause of the vulnerability is unknown, or reports may differ on the cause or impacts of the vulnerability. Reporters are uncertain of the true nature of the vulnerability, and there is little confidence in the validity of the reports or whether a static Base score can be applied given the differences described. An example is a bug report which notes that an intermittent but non-reproducible crash occurs, with evidence of memory corruption suggesting that denial of service, or possible more serious impacts, may result.
Reasonable (RC:R): Significant details are published, but researchers either do not have full confidence in the root cause, or do not have access to source code to fully confirm all of the interactions that may lead to the result. Reasonable confidence exists, however, that the bug is reproducible and at least one impact is able to be verified (Proof-of-concept exploits may provide this). An example is a detailed write-up of research into a vulnerability with an explanation (possibly obfuscated or 'left as an exercise to the reader') that gives assurances on how to reproduce the results.
Confirmed (RC:C): Detailed reports exist, or functional reproduction is possible (functional exploits may provide this). Source code is available to independently verify the assertions of the research, or the author or vendor of the affected code has confirmed the presence of the vulnerability.

CVSS 3.1: Environmental score

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 complementary/alternative security controls in place, Confidentiality, Integrity, and Availability. The metrics are the modified equivalent of base metrics and are assigned metric values based on the component placement in organization infrastructure.

Exploitability metrics

Attack vector (MAV)

This metric reflects the context by which vulnerability exploitation is possible. The Environmental Score increases the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable component.

Not defined (MAV:X): The value assigned to the corresponding Base metric is used.
Network (MAV:N): The vulnerable component is bound to the network stack and the set of possible attackers extends beyond the other options listed, up to and including the entire Internet. Such a vulnerability is often termed 'remotely exploitable' and can be thought of as an attack being exploitable at the protocol level one or more network hops away.
Adjacent network (MAV:A): The vulnerable component is bound to the network stack, but the attack is limited at the protocol level to a logically adjacent topology. This can mean an attack must be launched from the same shared physical (e.g., Bluetooth or IEEE 802.11) or logical (e.g., local IP subnet) network, or from within a secure or otherwise limited administrative domain (e.g., MPLS, secure VPN).
Local (MAV:L): The vulnerable component is not bound to the network stack and the attacker’s path is via read/write/execute capabilities. Either: the attacker exploits the vulnerability by accessing the target system locally (e.g., keyboard, console), or remotely (e.g., SSH); or the attacker relies on User Interaction by another person to perform actions required to exploit the vulnerability (e.g., tricking a legitimate user into opening a malicious document).
Physical (MAV:P): The attack requires the attacker to physically touch or manipulate the vulnerable component. Physical interaction may be brief or persistent.

Attack complexity (MAC)

Not defined (MAC:X): The value assigned to the corresponding Base metric is used.
Low (MAC:L): Specialized access conditions or extenuating circumstances do not exist. An attacker can expect repeatable success against the vulnerable component.
High (MAC:H): A successful attack depends on conditions beyond the attacker's control. That is, a successful attack cannot be accomplished at will, but requires the attacker to invest in some measurable amount of effort in preparation or execution against the vulnerable component before a successful attack can be expected. For example, a successful attack may require an attacker to: gather knowledge about the environment in which the vulnerable target/component exists; prepare the target environment to improve exploit reliability; or inject themselves into the logical network path between the target and the resource requested by the victim in order to read and/or modify network communications (e.g., a man in the middle attack).

Privileges required (MPR)

This metric describes the level of privileges an attacker must possess before successfully exploiting the vulnerability.

Not defined (MPR:X): The value assigned to the corresponding Base metric is used.
None (MPR:N): The attacker is unauthorized prior to attack, and therefore does not require any access to settings or files to carry out an attack.
Low (MPR:L): The attacker is authorized with (i.e., requires) privileges that provide basic user capabilities that could normally affect only settings and files owned by a user. Alternatively, an attacker with Low privileges may have the ability to cause an impact only to non-sensitive resources.
High (MPR:H): The attacker is authorized with (i.e., requires) privileges that provide significant (e.g., administrative) control over the vulnerable component that could affect component-wide settings and files.

User interaction (MUI)

Not defined (MUI:X): The value assigned to the corresponding Base metric is used.
None (MUI:N): The vulnerable system can be exploited without any interaction from any user.
Required (MUI:R): Successful exploitation of this vulnerability requires a user to take some action before the vulnerability can be exploited.

Scope (MS)

Not defined (MS:X): The value assigned to the corresponding Base metric is used.
Unchanged (MS:U): An exploited vulnerability can only affect resources managed by the same security authority. In this case, the vulnerable component and the impacted component are either the same, or both are managed by the same security authority.
Changed (MS:C): An exploited vulnerability can affect resources beyond the security scope managed by the security authority of the vulnerable component. In this case, the vulnerable component and the impacted component are different and managed by different security authorities.

Impact metrics

Confidentiality impact (MC)

Not defined (MC:X): The value assigned to the corresponding Base metric is used.
None (MC:N): There is no loss of confidentiality within the impacted component.
Low (MC:L): There is some loss of confidentiality. Access to some restricted information is obtained, but the attacker does not have control over what information is obtained, or the amount or kind of loss is limited. The information disclosure does not cause a direct, serious loss to the impacted component.
High (MC:H): There is total loss of confidentiality, resulting in all resources within the impacted component being divulged to the attacker. Alternatively, access to only some restricted information is obtained, but the disclosed information presents a direct, serious impact.

Integrity impact (MI)

This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information.

Not defined (X): The value assigned to the corresponding Base metric is used.
None: There is no loss of integrity within the impacted component.
Low: Modification of data is possible, but the attacker does not have control over the consequence of a modification, or the amount of modification is limited. The data modification does not have a direct, serious impact on the impacted component.
High: There is a total loss of integrity, or a complete loss of protection. For example, the attacker is able to modify any/all files protected by the impacted component. Alternatively, only some files can be modified, but malicious modification would present a direct, serious consequence to the impacted component.

Availability impact (MA)

Not defined (MA:X): The value assigned to the corresponding Base metric is used.
None (MA:N): There is no impact to availability within the impacted component.
Low (MA:L): Performance is reduced or there are interruptions in resource availability. Even if repeated exploitation of the vulnerability is possible, the attacker does not have the ability to completely deny service to legitimate users. The resources in the impacted component are either partially available all of the time, or fully available only some of the time, but overall there is no direct, serious consequence to the impacted component.
High (MA:H): There is total loss of availability, resulting in the attacker being able to fully deny access to resources in the impacted component; this loss is either sustained (while the attacker continues to deliver the attack) or persistent (the condition persists even after the attack has completed). Alternatively, the attacker has the ability to deny some availability, but the loss of availability presents a direct, serious consequence to the impacted component (e.g., the attacker cannot disrupt existing connections, but can prevent new connections; the attacker can repeatedly exploit a vulnerability that, in each instance of a successful attack, leaks a only small amount of memory, but after repeated exploitation causes a service to become completely unavailable).

Impact subscore modifiers

Confidentiality requirement (CR)

Not defined (CR:X): Assigning this value indicates there is insufficient information to choose one of the other values, and has no impact on the overall Environmental Score, i.e., it has the same effect on scoring as assigning Medium.
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): Assigning this value to the metric will not influence the score.
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).

Integrity requirement (IR)

These metrics enable the analyst to customize the CVSS score depending on the importance of the Integrity of the affected IT asset to a user’s organization, relative to other impacts. This metric modifies the environmental score by reweighting the Modified Integrity impact metric versus the other modified impacts.

Not defined (IR:X): Assigning this value indicates there is insufficient information to choose one of the other values, and has no impact on the overall Environmental Score, i.e., it has the same effect on scoring as assigning Medium.
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): Assigning this value to the metric will not influence the score.
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).

Availability requirement (AR)

These metrics enable the analyst to customize the CVSS score depending on the importance of the Availability of the affected IT asset to a user’s organization, relative to other impacts. This metric modifies the environmental score by reweighting the Modified Availability impact metric versus the other modified impacts.

Not defined (AR:X): Assigning this value indicates there is insufficient information to choose one of the other values, and has no impact on the overall Environmental Score, i.e., it has the same effect on scoring as assigning Medium.
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): Assigning this value to the metric will not influence the score.
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).

CVSS 2.1

Base CVSS score

Every vulnerability in the NVD starts with a base CVSS score. The base metric group captures the characteristics of a vulnerability that are constant with time and across user environments. The Access Vector, Access Complexity, and Authentication metrics capture how the vulnerability is accessed and whether or not extra conditions are required to exploit it. The three impact metrics measure how a vulnerability, if exploited, will directly affect an IT asset, where the impacts are independently defined as the degree of loss of confidentiality, integrity, and availability. For example, a vulnerability could cause a partial loss of integrity and availability, but no loss of confidentiality.

You cannot modify this base score, but you can modify the temporal and environmental scores by assessing your particular device's situation. Every metric in these two sections is set to Not defined (X) by default, which has the highest impact on the CVSS score.

All definitions are extracted from first.org's CVSS v2 calculator.

CVSS base score is divided into Exploitability and Impact metrics. Exploitability metrics include Attack vector, Access complexity, and Authentication, while Impact metrics include Confidentiality impact, Integrity impact, and Availability impact.

Read a CVSS 2 vector string

For CVSS 2, each section separated by a / in a vector string corresponds to one of the subcategories in the Base, Supplemental, Environmental, and Threat categories. Thus, a string such as this:

AV:N/AC:H/Au:N/C:P/I:P/A:P/E:POC/RL:OF/RC:UC

indicates that the Access Vector is Network, Access Complexity is High, Authentication is None, and that the Confidentiality Impact is Partial, Integrity Impact is Partial, and Availability Impact is Partial. It also indicates that Exploitability is Proof of concept code, Remediation Level is Official fix, and Report Confidence is Unconfirmed.

Note that since CVSS 2 was the first CVSS severity scoring standard, it is not appended with a version.

Exploitability metrics

Access vector (AV)

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)

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. If a race condition exists, the window is very narrow.
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). The attack requires a small amount of social engineering that might occasionally fool cautious users (e.g., phishing attacks that modify a web browser’s status bar to show a false link, having to be on someone’s “buddy” list before sending an IM exploit).
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)

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): One instance of authentication is required to access and exploit the vulnerability.
None (Au:N): Authentication is not required to access and exploit the vulnerability.

Impact metrics

Confidentiality impact (C)

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)

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)

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.

CVSS 2: Temporal score

The threat posed by a vulnerability may change over time. Three such factors that CVSS captures are: confirmation of the technical details of a vulnerability, the remediation status of the vulnerability, and the availability of exploit code or techniques. Since temporal metrics are optional they each include a metric value that has no effect on the score. This value is used when the user feels the particular metric does not apply and wishes to "skip over" it.

Exploitability (E)

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.
Unproven that exploit exists (E:U): No exploit code is available, or an exploit is entirely theoretical.
Proof-of-Concept code (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 exploit exists (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).

Remediation level (RL)

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.
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.

Report confidence (RC)

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.
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.

CVSS 2: Environmental score

Different environments can have an immense bearing on the risk that a vulnerability poses to an organization and its stakeholders. The CVSS environmental metric group captures the characteristics of a vulnerability that are associated with a user's IT environment. Since environmental metrics are optional they each include a metric value that has no effect on the score. This value is used when the user feels the particular metric does not apply and wishes to 'skip over' it.

CVSS environmental score is divided into General modifiers and Impact subscore modifiers. General modifers include Collateral damage potential and Target distribution, while Impact subscore modifiers include Confidentiality requirement, Integrity requirement, and Availability requirement.

General modifiers

Collateral damage potential (CDP)

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.
None (CDP:N): There is no potential for loss of life, physical assets, productivity or revenue.
Low (light loss) (CPD: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 (catastrophic loss) (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.

Target distribution (TD)

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.
None [0%] (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 [0-25%] (TD:L): Targets exist inside the environment, but on a small scale. Between 1% - 25% of the total environment is at risk.
Medium [26-75%] (TD:M): Targets exist inside the environment, but on a medium scale. Between 26% - 75% of the total environment is at risk.
High [76-100%] (TD:H): Targets exist inside the environment on a considerable scale. Between 76% - 100% of the total environment is considered at risk.

Impact subscore modifiers

Confidentiality requirement (CR)

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.
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).

Integrity requirement (IR)

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.
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).

Availability requirement (AR)

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.
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).

PreviousUnderstand issue severity level NextFind out if a vulnerability impacts your products

Last updated 8 months ago