Google Alert – NVD – CVSS v2 Calculator (CVE Vulnerability)

CVSS Version 2

Source:
NIST

This page shows the components of the CVSS score for example and allows you to refine the CVSS base score. Please read the CVSS standards guide to fully understand how to score CVSS vulnerabilities and to interpret CVSS scores. The scores are computed in sequence such that the Base Score is used to calculate the Temporal Score and the Temporal Score is used to calculate the Environmental Score.

Alert

Please fill in all base score metrics in order to generate a score!

CVSS Base Score:
{{vm.baseScore}}
Impact Subscore:
{{vm.impactScore}}
Exploitability Subscore:
{{vm.exploitScore}}
CVSS Temporal Score:
{{vm.temporalScore}}
CVSS Environmental Score:
{{vm.environScore}}
Modified Impact Subscore:
{{vm.modImpactScore}}
Overall CVSS Score:
{{vm.overallScore}}




Show Equations

Base Score Metrics

Exploitability Metrics

Attack Vector (AV)*


Local (AV:L)
Adjacent Network (AV:A)
Network (AV:N)

Access Complexity (AC)*


High (AC:H)
Medium (AC:M)
Low (AC:L)

Authentication (Au)*


Multiple (Au:M)
Single (Au:S)
None (Au:N)

Impact Metrics

Confidentiality Impact (C)*


None (C:N)
Partial (C:P)
Complete (C:C)

Integrity Impact (I)*


None (I:N)
Partial (I:P)
Complete (I:C)

Availability Impact (A)*


None (A:N)
Partial (A:P)
Complete (A:C)

Temporal Score Metrics

Exploitability (E)


Not Defined (E:ND)
Unproven that exploit exists (E:U)
Proof of concept code (E:POC)
Functional exploit exists (E:F)
High (E:H)

Remediation Level (RL)


Not Defined (RL:ND)
Official fix (RL:OF)
Temporary fix (RL:TF)
Workaround (RL:W)
Unavailable (RL:U)

Report Confidence (RC)


Not Defined (RC:ND)
Unconfirmed (RC:UC)
Uncorroborated (RC:UR)
Confirmed (RC:C)

Environmental Score Metrics

General Modifiers

Collateral Damage Potential (CDP)


Not Defined (CDP:ND)
None (CDP:N)
Low (light loss) (CDP:L)
Low-Medium (CDP:LM)
Medium-High (CDP:MH)
High (catastrophic loss) (CDP:H)

Target Distribution (TD)


Not Defined (TD:ND)
None [0%] (TD:N)
Low [0-25%] (TD:L)
Medium [26-75%] (TD:M)
High [76-100%] (TD:H)

Impact Subscore Modifiers

Confidentiality Requirement (CR)


Not Defined (CR:ND)
Low (CR:L)
Medium (CR:M)
High (CR:H)

Integrity Requirement (IR)


Not Defined (IR:ND)
Low (IR:L)
Medium (IR:M)
High (IR:H)

Availability Requirement (AR)


Not Defined (AR:ND)
Low (AR:L)
Medium (AR:M)
High (AR:H)

Base Score Metrics

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

Access Vector (AV)

This metric reflects how the vulnerability is exploited. The more remote an attacker
can be to attack a host, the greater the vulnerability score.
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.

Other vulnerabilities, however, may require additional steps in order to be exploited. For example, a
vulnerability in an email client is only exploited after the user downloads and opens a tainted attachment.
The lower the required complexity, the higher the
vulnerability score.

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)

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. The possible values for
this metric are listed in Table 3. The fewer authentication instances that are required, the higher the
vulnerability score.

It is important to note that the Authentication metric is different from Access Vector. Here, authentication
requirements are considered once the system has already been accessed. Specifically, for locally
exploitable vulnerabilities, this metric should only be set to ‘single’ or ‘multiple’ if authentication is
needed beyond what is required to log into the system. An example of a locally exploitable vulnerability
that requires authentication is one affecting a database engine listening on a Unix domain socket (or some
other non-network interface). If the user must authenticate as a valid database user in order to exploit the
vulnerability, then this metric should be set to ‘single.’

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)

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. Increased confidentiality impact increases the vulnerability score.
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. Increased integrity impact increases the vulnerability score.
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. Increased availability impact increases the vulnerability score.
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 Score Metrics

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)

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.

Initially, real-world exploitation may only be theoretical. Publication of proof of concept code, functional
exploit code, or sufficient technical details necessary to exploit the vulnerability may follow.
Furthermore, the exploit code available may progress from a proof-of-concept demonstration to exploit
code that is successful in exploiting the vulnerability consistently. In severe cases, it may be delivered as
the payload of a network-based worm or virus.
The more easily a vulnerability can be exploited, the higher the vulnerability score.

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)

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. Each of these respective stages adjusts the temporal score downwards,
reflecting the decreasing urgency as remediation becomes final. The less official and permanent a fix, the higher the vulnerability score is.
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)

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. 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. The more a vulnerability is validated by the vendor
or other reputable sources, the higher the score.
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-ofconcept exploit code or widespread exploitation.



Environmental Score Metrics

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

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. Naturally, the greater
the damage potential, the higher the vulnerability score.
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) (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 (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)

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.
The possible values for this metric are listed in Table 11. The greater the proportion of vulnerable
systems, the higher the score.
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.

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

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,
That is, if an IT asset supports a business function for which availability is most important, the analyst
can assign a greater value to availability, relative to confidentiality and integrity. Each security
requirement has three possible values: low, medium, or high.
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).



Article source at https://nvd.nist.gov/vuln-metrics/cvss/v2-calculator%3Fversion%3D2%26name%3DCVE-2019-17295%26vector%3D(AV:N/AC:L/Au:S/C:P/I:P/A:P)