Common Vulnerability Scoring System Calculator CVE-2018-0517
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.
As of July 13th, 2022, the NVD no longer generates new information for CVSS v2. Existing CVSS v2 information will remain in the database but the NVD will no longer actively populate CVSS v2 for new CVEs. This change comes as CISA policies that rely on NVD data fully transition away from CVSS v2. NVD analysts will continue to use the reference information provided with the CVE and any publicly available information at the time of analysis to associate Reference Tags, CVSS v3.1, CWE, and CPE Applicability statements.
Please fill in all base score metrics in order to generate a score!
- CVSS Base Score:
- Impact Subscore:
- Exploitability Subscore:
- CVSS Temporal Score:
- CVSS Environmental Score:
- Modified Impact Subscore:
- Overall CVSS Score:
Base Score Metrics
Temporal Score Metrics
Environmental Score Metrics
- 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)
- Adjacent Network (AV:A)
- Network (AV:N)
- 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)
- Medium (AC:M)
- Low (AC:L)
- 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
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)
- 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)
- Complete (C:C)
- 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)
- Complete (I:C)
- 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)
- Complete (A:C)
- 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)
- Unproven that exploit exists (E:U)
- No exploit code is available, or an exploit is entirely theoretical.
- Proof of concept code (E:POC)
- Functional exploit exists (E:F)
- High (E:H)
- 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)
- Official fix (RL:OF)
- Temporary fix (RL:TF)
- Workaround (RL:W)
- 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)
- Unconfirmed (RC:UC)
- Uncorroborated (RC:UR)
- Confirmed (RC:C)
- 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)
- None (CDP:N)
- There is no potential for loss of life, physical assets, productivity or revenue.
- Low (light loss) (CDP:L)
- Low-Medium (CDP:LM)
- Medium-High (CDP:MH)
- High (catastrophic loss) (CDP:H)
- 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)
- None [0%] (TD:N)
- Low [0-25%] (TD:L)
- Medium [26-75%] (TD:M)
- High [76-100%] (TD:H)
- 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)
- 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)