This ontology provides a vocabulary and representation for a unified form of the Common Vulnerability Scoring System (CVSS) which provides an open framework for communicating the characteristics and impacts of IT vulnerabilities.
Be warned that this version is under heavy development.
Short code for describing score entities, usually used in string vectors to be less wordy.
Short code used for describing the entity, like AV or PR
CVSSv2 code
CVSSv3 code
A given score for a metric is greater than the subject metric score by some arbitrary amount.
Specifies a reference to the details for the base metrics
TODO: research and classify properly
Specifies a reference to the details for environmental metrics
Relates some vulnerability to some metric
Specifies a reference to the details for the Temporal Metrics
A given metric score is less than the subject metric score by some arbitrary amount.
CVSS Environmental score
CVSS Exploitability subscore
CVSS score
The base equation is the foundation of CVSS scoring. The base equation (formula version 2.10) is: 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*Authentication f(impact)= 0 if Impact=0, 1.176 otherwise
CVSS v2 Base metric score
If employed, the environmental equation will combine the environmental metrics with the temporal score to produce an environmental score ranging from 0 to 10. Further, this equation will produce a score no higher than the temporal score. The environmental equation is: EnvironmentalScore = round_to_1_decimal((AdjustedTemporal+ (10-AdjustedTemporal)*CollateralDamagePotential)*TargetDistribution) AdjustedTemporal = TemporalScore recomputed with the BaseScore's Impact sub-equation replaced with the AdjustedImpact equation AdjustedImpact = min(10,10.41*(1-(1-ConfImpact*ConfReq)*(1-IntegImpact*IntegReq) *(1-AvailImpact*AvailReq)))
CVSS v2 Environmental score
Specifies the base exploit sub-score asisgned to a vulnerability by a source Exploitability = 20* AccessVector*AccessComplexity*Authentication
CVSS v2 Exploitability subscore
Specifies the base impact sub-score assigned to a vulnerability by a source Impact = 10.41*(1-(1-ConfImpact)*(1-IntegImpact)*(1-AvailImpact))
CVSS v2 Impact subscore
TODO: Found in the JSON 1.1 NVD feed, but need to find the actual definition
CVSS v2 Insufficient information
CVSS v2 obtain all privilege
CVSS v2 obtain other privilege
CVSS v2 obtain user privilege
CVSS v2 Overall score
Specifies the CVSS v2 score
CVSS v2 score
CVSS v2 severity
If employed, the temporal equation will combine the temporal metrics with the base score to produce a temporal score ranging from 0 to 10. Further, the temporal score will produce a temporal score no higher than the base score, and no greater than 33% lower than the base score. The temporal equation is: TemporalScore = round_to_1_decimal(BaseScore*Exploitability *RemediationLevel*ReportConfidence)
TODO: This is similar to the CVSS v3 user interaction and needs homogenization
CVSS v2 user interaction required
A CVSS score is also represented as a vector string, a compressed textual representation of the values used to derive the score.
Specifies a compressed textual representation that reflects the values used to drive the CVSS score
Specifies a score, between 0 and 10, that represents the intrinsic and fundamental characteristics of a vulnerability that are consistent over time and user environments.
Specifies a score, between 0 and 10, that represents the characteristics of a vulnerability that change over time but not among user environments.
CVSS v3 Environmental score
Specifies the base exploit sub-score asisgned to a vulnerability by a source
CVSS v3 Exploitability subscore
Specifies the base impact sub-score assigned to a vulnerability by a source
CVSS v3 Impact subscore
Specifies the CVSS v3 Score
CVSS v3 score
Specifies a score, between 0 and 10, that represents the characteristics of a vulnerability that are relevant and unique to a particular user's environments.
Specifies the time and date when the CVSS base metrics were determined
Specifies the source of the CVSS metric in the form of a URL
The base metric group captures the characteristics of a vulnerability that are constant with time and across user environments.
CVSS Base metric
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 metrics value based on the component placement in organization infrastructure.
Exploitability metrics reflect the characteristics of the thing that is vulnerable, which we refer to formally as the vulnerable component. Therefore, each of the Exploitability metrics should be scored relative to the vulnerable component, and reflect the properties of the vulnerability that lead to a successful attack.
CVSS Exploitability metric
The Impact metrics refer to the properties of the impacted component. Whether a successfully exploited vulnerability affects one or more components, the impact metrics are scored according to the component that suffers the worst outcome that is most directly and predictably associated with a successful attack. That is, analysts should constrain impacts to a reasonable, final outcome which they are confident an attacker is able to achieve. If a scope change has not occurred, the Impact metrics should reflect the confidentiality, integrity, and availability (CIA) impact to the vulnerable component. However, if a scope change has occurred, then the Impact metrics should reflect the CIA impact to either the vulnerable component, or the impacted component, whichever suffers the most severe outcome.
CVSS Impact metric
CVSS metric of vulnerability characteristics
CVSS metric group
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. The full effect on the environmental score is determined by the corresponding Modified Base Impact metrics. That is, these metrics modify the environmental score by reweighting the Modified Confidentiality, Integrity, and Availability impact metrics. For example, the Modified Confidentiality impact (MC) metric has increased weight if the Confidentiality Requirement (CR) is High. Likewise, the Modified Confidentiality impact metric has decreased weight if the Confidentiality Requirement is Low. The Modified Confidentiality impact metric weighting is neutral if the Confidentiality Requirement is Medium. This same process is applied to the Integrity and Availability requirements. Note that the Confidentiality Requirement will not affect the Environmental score if the (Modified Base) confidentiality impact is set to None. Also, increasing the Confidentiality Requirement from Medium to High will not change the Environmental score when the (Modified Base) impact metrics are set to High. This is because the modified impact sub score (part of the Modified Base score that calculates impact) is already at a maximum value of 10.
CVSS Security Requirement
Defines the characteristics of a vulnerability that change over time but not among user environments.
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.
CVSS v2 Access complexity
This metric reflects how the vulnerability is exploited.
CVSS v2 Access vector
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.
CVSS v2 Authentication
This metric measures the impact to the availability of the impacted component resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the impacted component, this metric 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. This metric value increases with the consequence to the impacted component.
CVSS v2 Availability impact
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 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.
CVSS v2 Availability requirement
CVSS v2 Base metric
Defines the intrinsic and fundamental characteristics of a vulnerability that are constant with time and across user environments
CVSS v2 base metrics
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.
CVSS v2 Collateral damage potential
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. The possible values for this metric are listed in Table 4. Increased confidentiality impact increases the vulnerability score.
CVSS v2 Confidentiality impact
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. That is, if an IT asset supports a business function for which Confidentiality is most important, the analyst can assign a greater value to Confidentiality relative to Availability and Integrity. This security requirement has three possible values: Low, Medium, or High. Note that the Confidentiality Requirement will not affect the Environmental score if the (Modified Base) confidentiality impact is set to None. Also, increasing the Confidentiality Requirement from Medium to High will not change the Environmental score when the (Modified Base) impact metrics are set to High. This is because the modified impact sub score (part of the Modified Base score that calculates impact) is already at a maximum value of 10.
CVSS v2 Confidentiality requirement
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 v2 Environmental metric
CVSS v2 environmental metrics
The Exploitability metrics reflect the characteristics of the thing that is vulnerable, which we refer to formally as the vulnerable component. Therefore, each of the Exploitability metrics listed below should be scored relative to the vulnerable component, and reflect the properties of the vulnerability that lead to a successful attack.
CVSS v2 Exploitability
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.
CVSS v2 Impact metric
This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. This metric value increases with the consequence to the impacted component.
CVSS v2 Integrity impact
This metric enables 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 Integrity. That is, if an IT asset supports a business function for which Integrityis most important, the analyst can assign a greater value to Integrity relative to Confidentiality and Availability. Each security requirement has three possible values: Low, Medium, or High.
CVSS v2 Integrity requirement
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 browsers status bar to show a false link, having to be on someones buddy list before sending an IM exploit).
CVSS v2 Medium access complexity
The Common Vulnerability Scoring System (CVSS) provides an open framework for communicating the characteristics and impacts of IT vulnerabilities. CVSS consists of 3 groups: Base, Temporal and Environmental. Each group produces a numeric score ranging from 0 to 10, and a Vector, a compressed textual representation that reflects the values used to derive the score. The Base group represents the intrinsic qualities of a vulnerability. The Temporal group reflects the characteristics of a vulnerability that change over time. The Environmental group represents the characteristics of a vulnerability that are unique to any user's environment. CVSS enables IT managers, vulnerability bulletin providers, security vendors, application vendors and researchers to all benefit by adopting this common language of scoring IT vulnerabilities.
CVSS v2 metric of vulnerability characteristics
The CVSS base group defines and communicates the fundamental characteristics of a vulnerability. This objective approach to characterizing vulnerabilities provides users with a clear and intuitive representation of a vulnerability.
CVSS v2 metric group
Assigning this value to the metric will not influence the score. It is a signal to a scoring equation to skip this metric.
CVSS v2 Not-defined report confidence
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.
CVSS v2 Remediation level
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. The more a vulnerability is validated by the vendor or other reputable sources, the higher the score.
CVSS v2 Report confidence
These metrics enable the analyst to customize the CVSS score depending on the importance of the affected IT asset to a users 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.
CVSS v2 Security requirement
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.
CVSS v2 Target distribution
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.
CVSS v2 Temporal metric
CVSS v2 temporal metrics
This metric describes the conditions beyond the attacker’s control that must exist in order to exploit the vulnerability. As described below, such conditions may require the collection of more information about the target, the presence of certain system configuration settings, or computational exceptions. Importantly, the assessment of this metric excludes any requirements for user interaction in order to exploit the vulnerability (such conditions are captured in the User Interaction metric). This metric value is largest for the least complex attacks.
CVSS v3 Attack complexity
This metric reflects the context by which vulnerability exploitation is possible. This metric value (and consequently the Base score) will be larger the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable component. The assumption is that the number of potential attackers for a vulnerability that could be exploited from across the Internet is larger than the number of potential attackers that could exploit a vulnerability requiring physical access to a device, and therefore warrants a greater score.
CVSS v3 Attack vector
CVSS v3 Availability impact
CVSS v3 Availability requirement
The Base metric group represents the intrinsic characteristics of a vulnerability that are constant over time and across user environments.
CVSS v3 Base metric
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. This metric value increases with the degree of loss to the impacted component.
CVSS v3 Confidentiality impact
CVSS v3 Confidentiality requirement
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 values based on the component placement within organizational infrastructure.
CVSS v3 Environmental metric
CVSS v3 environmental metrics
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. 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 or other automated attack tools.
CVSS v3 Exploit code maturity
The Exploitability metrics reflect the characteristics of the thing that is vulnerable, which we refer to formally as the vulnerable component. Therefore, each of the Exploitability metric is scored relative to the vulnerable component, and reflect the properties of the vulnerability that lead to a successful attack.
CVSS v3 Exploitability metric
Loss of Confidentiality is likely to have a catastrophic adverse effect on the organization or individuals associated with the organization (e.g., employees, customers).
CVSS v3 High confidentiality requirement
Loss of Integrity is likely to have a catastrophic adverse effect on the organization or individuals associated with the organization (e.g., employees, customers).
CVSS v3 High integrity requirement
The Impact metrics reflect the direct consequence of a successful exploit, and represent the consequence to the thing that suffers the impact, which we refer to formally as the impacted component. The Impact metrics capture the effects of a successfully exploited vulnerability on the component that suffers the worst outcome that is most directly and predictably associated with the attack. Analysts should constrain impacts to a reasonable, final outcome which they are confident an attacker is able to achieve.
CVSS v3 Impact metric
CVSS v3 Integrity impact
CVSS v3 Integrity requirement
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).
CVSS v3 Low confidentiality requirement
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).
CVSS v3 Low integrity requirement
Loss of Confidentiality is likely to have a serious adverse effect on the organization or individuals associated with the organization (e.g., employees, customers).
CVSS v3 Medium confidentiality requirement
Loss of Integrity is likely to have a serious adverse effect on the organization or individuals associated with the organization (e.g., employees, customers).
CVSS v3 Medium integrity requirement
The Common Vulnerability Scoring System (CVSS) provides a way to capture the principal characteristics of a vulnerability and produce a numerical score reflecting its severity. The numerical score can then be translated into a qualitative representation (such as low, medium, high, and critical) to help organizations properly assess and prioritize their vulnerability management processes.
CVSS v3 Metric
CVSS v3 metric group
These metrics enable the analyst to adjust the Base metrics according to modifications that exist within the analyst’s environment. That is, if an environment has made general changes for the affected software that differs in a way which would affect its Exploitability, Scope, or Impact, then the environment can reflect this via an appropriately-modified, Environmental score. The full effect on the Environmental score is determined by the corresponding Base metrics. That is, these metrics modify the Environmental score by reassigning the (Base) metrics values, prior to applying the (Environmental) Security Requirements. For example, the default configuration for a vulnerable component may be to run a listening service with administrator privileges, for which a compromise might grant an attacker Confidentiality, Integrity, and Availability impacts that are all High. Yet, in the analyst’s environment, that same Internet service might be running with reduced privileges; in that case, the Modified Confidentiality, Modified Integrity, and Modified Availability might each be set to Low. For brevity, only the names of the Modified Base metrics are mentioned. Each Modified Environmental metric has the same values as its corresponding Base metric, plus a value of Not Defined. The intent of this metric is to define the mitigations in place for a given environment. It is acceptable to use the Modified metrics to describe situations that increase the Base score. For example, the default configuration of a component may be to require high privileges (PR: High) in order to access a particular function, but in the analyst’s environment, there may be no privileges required (PR: None). The analyst can set MPR: None to reflect this more serious condition for their environment.
Assigning this value to the metric will not influence the score. It is a signal to the equation to skip this metric.
CVSS v3 Not-defined confidentiality requirement
CVSS v3 Not-defined integrity requirement
This metric describes the level of privileges an attacker must possess before successfully exploiting the vulnerability. This metric if greatest if no privileges are required.
CVSS v3 Privileges required
CVSS v3 Remediation level
CVSS v3 Report confidence
An important property captured by CVSS v3.0 is the ability for a vulnerability in one software component to impact resources beyond its means, or privileges. This consequence is represented by the metric Authorization Scope, or simply Scope. Formally, Scope refers to the collection of privileges defined by a computing authority (e.g. an application, an operating system, or a sandbox environment) when granting access to computing resources (e.g. files, CPU, memory, etc). These privileges are assigned based on some method of identification and authorization. In some cases, the authorization may be simple or loosely controlled based upon predefined rules or standards. For example, in the case of Ethernet traffic sent to a network switch, the switch accepts traffic that arrives on its ports and is an authority that controls the traffic flow to other switch ports. When the vulnerability of a software component governed by one authorization scope is able to affect resources governed by another authorization scope, a Scope change has occurred. Intuitively, one may think of a scope change as breaking out of a sandbox, and an example would be a vulnerability in a virtual machine that enables an attacker to delete files on the host OS (perhaps even its own VM). In this example, there are two separate authorization authorities: one that defines and enforces privileges for the virtual machine and its users, and one that defines and enforces privileges for the host system within which the virtual machine runs. A scope change would not occur, for example, with a vulnerability in Microsoft Word that allows an attacker to compromise all system files of the host OS, because the same authority enforces privileges of the user’s instance of Word, and the host’s system files.
CVSS v3 Scope
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.
CVSS v3 Security requirement
CVSS v3 Temporal metric
CVSS v3 temporal metrics
This metric captures the requirement for a user, other than the attacker, to participate in the successful compromise of 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. This metric value is greatest when no user interaction is required.
CVSS v3 User interaction
Metric group
CVSS v2 Adjacent access vector
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.
CVSS v2 Complete availability impact
There is a total shutdown of the affected resource. The attacker can render the resource completely unavailable.
CVSS v2 Complete confidentiality impact
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.)
CVSS v2 Complete integrity impact
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.
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 v2 Confirmed report confidence
CVSS v2 Functional exploitability
Functional exploit code is available. The code works in most situations where the vulnerability exists.
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.
CVSS v2 High access complexity
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 v2 High availability requirement
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.
CVSS v2 High collateral damage potential
CVSS v2 High confidentiality requirement
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).
CVSS v2 High exploitability
CVSS v2 High integrity requirement
Targets exist inside the environment on a considerable scale. Between 76% - 100% of the total environment is considered at risk.
CVSS v2 High target distribution
CVSS v2 Local access vector
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).
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).
CVSS v2 Low access complexity
CVSS v2 Low availability requirement
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).
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.
CVSS v2 Low collateral damage potential
CVSS v2 Low confidentiality requirement
CVSS v2 Low integrity requirement
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.
CVSS v2 Low-medium collateral damage potential
CVSS v2 Low target distribution
Targets exist inside the environment, but on a small scale. Between 1% - 25% of the total environment is at risk.
CVSS v2 Medium availability requirement
Loss of Availability is likely to have a serious adverse effect on the organization or individuals associated with the organization (e.g., employees, customers).
CVSS v2 Medium confidentiality requirement
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.
CVSS v2 Medium-Hhgh collateral damage potential
CVSS v2 Medium integrity requirement
CVSS v2 Medium target distribution
Targets exist inside the environment, but on a medium scale. Between 26% - 75% of the total environment is at risk.
CVSS v2 Multiple authentication
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.
CVSS v2 Network access vector
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.
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.
CVSS v2 No target distribution
Authentication is not required to exploit the vulnerability.
CVSS v2 No authentication
There is no impact to the availability of the system.
CVSS v2 No availability impact
CVSS v2 No collateral damage potential
There is no potential for loss of life, physical assets, productivity or revenue.
There is no impact to the confidentiality of the system.
CVSS v2 No confidentiality impact
CVSS v2 No integrity impact
There is no impact to the integrity of the system.
CVSS v2 Not-defined availability requirement
CVSS v2 Not-defined collateral damage potential
CVSS v2 Not-defined confidentiality requirement
CVSS v2 Not-defined exploitability
CVSS v2 Not-defined integrity requirement
CVSS v2 Not-defined remediation level
CVSS v2 Not-defined target distribution
A complete vendor solution is available. Either the vendor has issued an official patch, or an upgrade is available.
CVSS v2 Official fix remediation
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.
CVSS v2 Partial availability impact
CVSS v2 Partial confidentiality impact
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.
CVSS v2 Partial integrity impact
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.
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.
CVSS v2 Proof-of-concept exploitability
CVSS v2 Single authentication
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).
CVSS v2 Temporary fix remediation
There is an official but temporary fix available. This includes instances where the vendor issues a temporary hotfix, tool, or workaround.
There is either no solution available or it is impossible to apply.
CVSS v2 Unavailable remediation
CVSS v2 Unconfirmed report confidence
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.
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.
CVSS v2 Uncorroborated report confidence
CVSS v2 Unproven exploitability
No exploit code is available, or an exploit is entirely theoretical.
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.
CVSS v2 Workaround remediation
A vulnerability exploitable with adjacent network access means the vulnerable component is bound to the network stack, however the attack is limited to the same shared physical (e.g. Bluetooth, IEEE 802.11), or logical (e.g. local IP subnet) network, and cannot be performed across an OSI layer 3 boundary (e.g. a router). An example of an Adjacent attack would be an ARP (IPv4) or neighbor discovery (IPv6) flood leading to a denial of service on the local LAN segment. See also CVE-2013-6014.
CVSS v3 Adjacent attack vector
CVSS v3 Changed scope
An exploited vulnerability can affect resources beyond the authorization privileges intended by the vulnerable component. In this case the vulnerable component and the impacted component are different.
CVSS v3 Confirmed report confidence
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 v3 Functional exploit code maturity
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 depend on an attacker overcoming any of the following conditions: - The attacker must conduct target-specific reconnaissance. For example, on target configuration settings, sequence numbers, shared secrets, etc. - The attacker must prepare the target environment to improve exploit reliability. For example, repeated exploitation to win a race condition, or overcoming advanced exploit mitigation techniques. - The attacker must inject herself 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. man in the middle attack).
CVSS v3 High attack complexity
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 v3 High availability impact
CVSS v3 High availability requirement
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. For example, an attacker steals the administrator's password, or private encryption keys of a web server.
CVSS v3 High confidentiality impact
CVSS v3 High exploit code maturity
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.
CVSS v3 High integrity impact
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.
CVSS v3 High privileges required
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.
A vulnerability exploitable with Local access means that the vulnerable component is not bound to the network stack, and the attacker’s path is via read/write/execute capabilities. In some cases, the attacker may be logged in locally in order to exploit the vulnerability, otherwise, she may rely on User Interaction to execute a malicious file.
CVSS v3 Local attack vector
Specialized access conditions or extenuating circumstances do not exist. An attacker can expect repeatable success against the vulnerable component.
CVSS v3 Low attack complexity
There is reduced performance or 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.
CVSS v3 Low availability impact
CVSS v3 Low availability requirement
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 constrained. The information disclosure does not cause a direct, serious loss to the impacted component.
CVSS v3 Low confidentiality impact
Modification of data is possible, but the attacker does not have control over the consequence of a modification, or the amount of modification is constrained. The data modification does not have a direct, serious impact on the impacted component.
CVSS v3 Low integrity impact
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.
CVSS v3 Low privileges required
CVSS v3 Medium availability requirement
A vulnerability exploitable with network access means the vulnerable component is bound to the network stack and the attacker's path is through OSI layer 3 (the network layer). Such a vulnerability is often termed “remotely exploitable” and can be thought of as an attack being exploitable one or more network hops away (e.g. across layer 3 boundaries from routers). An example of a network attack is an attacker causing a denial of service (DoS) by sending a specially crafted TCP packet from across the public Internet (e.g. CVE-2004-0230).
CVSS v3 Network attack vector
There is no impact to availability within the impacted component.
CVSS v3 No availability impact
There is no loss of confidentiality within the impacted component.
CVSS v3 No confidentiality impact
CVSS v3 No integrity impact
There is no loss of integrity within the impacted component.
CVSS v3 No privileges required
The attacker is unauthorized prior to attack, and therefore does not require any access to settings or files to carry out an attack.
The vulnerable system can be exploited without interaction from any user.
CVSS v3 No user interaction
CVSS v3 Not-defined availability requirement
CVSS v3 Not-defined exploit code maturity
CVSS v3 Not-defined remediation
CVSS v3 Not-defined report confidence
CVSS v3 Official fix remediation
CVSS v3 Physical attack vector
A vulnerability exploitable with Physical access requires the attacker to physically touch or manipulate the vulnerable component. Physical interaction may be brief (e.g. evil maid attack) or persistent. An example of such an attack is a cold boot attack which allows an attacker to access to disk encryption keys after gaining physical access to the system, or peripheral attacks such as Firewire/USB Direct Memory Access attacks.
CVSS v3 Proof-of-concept exploit code maturity
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.
CVSS v3 Reasonable report confidence
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.
Successful exploitation of this vulnerability requires a user to take some action before the vulnerability can be exploited. For example, a successful exploit may only be possible during the installation of an application by a system administrator.
CVSS v3 Required user interaction
CVSS v3 Temporary fix remediation
CVSS v3 Unavailable remediation
CVSS v3 Unchanged scope
An exploited vulnerability can only affect resources managed by the same authority. In this case the vulnerable component and the impacted component are the same.
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.
CVSS v3 Unknown report confidence
CVSS v3 Unproven exploit code maturity
No exploit code is available, or an exploit is theoretical.
CVSS v3 Workaround remediation