CVSS v4.0 Specification Document (2024)

Also available in PDF format.

Document Version: 1.2

The Common Vulnerability Scoring System (CVSS) is an open framework forcommunicating the characteristics and severity of software vulnerabilities. CVSSconsists of four metric groups: Base, Threat, Environmental, and Supplemental.The Base group represents the intrinsic qualities of a vulnerability that areconstant over time and across user environments, the Threat group reflects thecharacteristics of a vulnerability that change over time, and the Environmentalgroup represents the characteristics of a vulnerability that are unique to auser's environment. Base metric values are combined with default values thatassume the highest severity for Threat and Environmental metrics to produce ascore ranging from 0 to 10. To further refine a resulting severity score, Threatand Environmental metrics can then be amended based on applicable threatintelligence and environmental considerations. Supplemental metrics do notmodify the final score, and are used as additional insight into thecharacteristics of a vulnerability. A CVSS vector string consists of acompressed textual representation of the values used to derive the score. Thisdocument provides the official specification for CVSS version 4.0.

The most current CVSS resources can be found at https://www.first.org/cvss/

CVSS is owned and managed by FIRST.Org, Inc. (FIRST), a US-based non-profitorganization, whose mission is to help computer security incident response teamsacross the world. FIRST reserves the right to update CVSS and this documentperiodically at its sole discretion. While FIRST owns all rights and interest inCVSS, it licenses it to the public freely for use, subject to the conditionsbelow. Membership in FIRST is not required to use or implement CVSS. FIRST does,however, require that any individual or entity using CVSS give properattribution, where applicable, that CVSS is owned by FIRST and used bypermission. Further, FIRST requires as a condition of use that any individual orentity which publishes CVSS data conforms to the guidelines described in thisdocument and provides both the score and the vector string so others canunderstand how the score was derived.

The Common Vulnerability Scoring System (CVSS) captures the principal technicalcharacteristics of software, hardware and firmware vulnerabilities. Its outputsinclude numerical scores indicating the severity of a vulnerability relative toother vulnerabilities.

CVSS is composed of four metric groups: Base, Threat, Environmental, andSupplemental. The Base Score reflects the severity of a vulnerability accordingto its intrinsic characteristics which are constant over time and assumes thereasonable worst-case impact across different deployed environments. The ThreatMetrics adjust the severity of a vulnerability based on factors, such as theavailability of proof-of-concept code or active exploitation. The EnvironmentalMetrics further refine the resulting severity score to a specific computingenvironment. They consider factors such as the presence of mitigations in thatenvironment and the criticality attributes of the vulnerable system. Finally,the Supplemental Metrics describe and measure additional extrinsic attributes ofa vulnerability, intended to add context.

Base Metrics, and optionally Supplemental Metrics, are provided by theorganization maintaining the vulnerable system, or a third party assessment ontheir behalf. Threat and Environmental information is available to only the endconsumer. Consumers of CVSS should enrich the Base metrics with Threat andEnvironmental metric values specific to their use of the vulnerable system toproduce a score that provides a more comprehensive input to risk assessmentspecific to their organization. Consumers may use CVSS information as input toan organizational vulnerability management process that also considers factorsthat are not part of CVSS in order to rank the threats to their technologyinfrastructure and make informed remediation decisions. Such factors mayinclude, but are not limited to: regulatory requirements, number of customersimpacted, monetary losses due to a breach, life or property threatened, orreputational impacts of a potential exploited vulnerability. These factors areoutside the scope of CVSS.

The benefits of CVSS include the provisioning of a standardized vendor andplatform agnostic vulnerability scoring methodology. It is an open framework,providing transparency to the individual characteristics and methodology used toderive a score.

Metrics

CVSS is composed of four metric groups: Base, Threat, Environmental, andSupplemental, each consisting of a set of metrics, as shown in Figure 1.

Figure 1: CVSS Metric Groups

The Base metric group represents the intrinsic characteristics of avulnerability that are constant over time and across user environments. It iscomposed of two sets of metrics: the Exploitability metrics and the Impactmetrics.

The Exploitability metrics reflect the ease and technical means by which thevulnerability can be exploited. That is, they represent characteristics of the“thing that is vulnerable”, which we refer to formally as the “vulnerablesystem”. The Impact metrics reflect the direct consequence of a successfulexploit, and represent the consequence to the “things that suffer the impact”,which may include impact on the vulnerable system and/or the downstream impacton what is formally called the “subsequent system(s)”.

While the vulnerable system is typically a software application, operatingsystem, module, driver, etc. (or possibly a hardware device), the subsequentsystem could be any of those examples but also includes human safety. Thispotential for measuring the impact of a vulnerability other than the vulnerablesystem, was a key feature introduced with CVSS v3.0. This property (formerlyknown as “Scope”), is captured by the separation of impacts to the vulnerablesystem and to subsequent systems, discussed later.

The Threat metric group reflects the characteristics of a vulnerability relatedto threat that may change over time but not necessarily across userenvironments. For example, confirmation that the vulnerability has neither beenexploited nor has any proof-of-concept exploit code or instructions publiclyavailable will lower the resulting CVSS score. The values found in this metricgroup may change over time.

The Environmental metric group represents the characteristics of a vulnerabilitythat are relevant and unique to a particular consumers’ environment.Considerations include the presence of security controls which may mitigate someor all consequences of a successful attack, and the relative importance of avulnerable system within a technology infrastructure.

The Supplemental metric group includes metrics that provide context as well asdescribe and measure additional extrinsic attributes of a vulnerability. Theresponse to each metric within the Supplemental metric group is to be determinedby the CVSS consumer, allowing the usage of an end-user risk analysis system toapply locally significant severity to the metrics and values. No metric will,within its specification, have any impact on the final CVSS score (e.g.CVSS-BTE). Consumer organizations may then assign importance and/or effectiveimpact of each metric, or set/combination of metrics, giving them more, less, orabsolutely no effect on the categorization, prioritization, and assessment ofthe vulnerability. Metrics and values will simply convey additional extrinsiccharacteristics of the vulnerability itself.

Each of these metrics are discussed in further detail below. The User Guidecontains scoring rubrics for the Base Metrics that may be useful when scoring.

Assessment

When the Base metrics are assigned values by an analyst, the Base metricsassessment results in a score ranging from 0.0 to 10.0.

The Base metrics assessment can then be further refined by assessing the Threatand Environmental metrics in order to more accurately reflect the relativeseverity posed by a vulnerability to a user’s environment at a specific point intime. Assessment of the Threat and Environmental metrics is not required, but ishighly recommended for more meaningful results.

Generally, the Base metrics are specified by vulnerability bulletin analysts,product vendors, or application vendors because they typically possess the mostaccurate information about the characteristics of a vulnerability. The Threatand Environmental metrics are specified by consumer organizations because theyare best able to assess the potential impact of a vulnerability within their owncomputing environment, at a given point in time.

Assessing CVSS metrics also produces a vector string, a textual representationof the metric values used to derive a quantitative score and qualitative ratingfor the vulnerability. This vector string is a specifically formatted textstring that contains each value assigned to each metric, and should be displayedwith the vulnerability score.

The scoring assessment and vector string are explained further below.

Note that all metrics should be assessed under the assumption that the attackerhas perfect knowledge of the vulnerability. That is, the analyst need notconsider the means by which the vulnerability was identified. In addition, it islikely that many different types of individuals will be assessingvulnerabilities (e.g., software vendors, vulnerability bulletin analysts,security product vendors), however, note that CVSS assessment is intended to beagnostic to the individual and their organization.

Nomenclature

Numerical CVSS Scores have very different meanings based on the metrics used tocalculate them. Regarding prioritization, the usefulness of a numerical CVSSscore is directly proportional to the CVSS metrics leveraged to generate thatscore. Therefore, numerical CVSS scores should be labeled using nomenclaturethat communicates the metrics used in its generation.

Additional Notes:

• This nomenclature should be used wherever a numerical CVSS value isdisplayed or communicated.

• The application of Environmental and Threat metrics is the responsibility ofthe CVSS consumer. Assessment providers such as product maintainers andother public/private entities such as the National Vulnerability Database(NVD) typically provide only the Base Scores enumerated as CVSS-B.

• The inclusion of the “E” in the nomenclature is appropriate if anyEnvironmental metrics are used to generate the resulting score.

• The inclusion of the “T” in the nomenclature is appropriate if any Threatmetrics are used to generate the resulting score.

• In CVSS v4.0, Base, Threat, and Environmental metric values are alwaysconsidered in the calculation of the final score. The absence of explicitThreat and/or Environmental metric selections will still result in acomplete score using default (“Not Defined”) values. This nomenclature makesit explicit and clear about which metric groups were considered in thenumerical CVSS score provided.

Exploitability Metrics

As previously mentioned, the Exploitability metrics reflect the characteristicsof the “thing that is vulnerable”, which we refer to formally as thevulnerable system. Therefore, each of the Exploitability metrics listed belowshould be assessed relative to the vulnerable system, and reflect the propertiesof the vulnerability that lead to a successful attack.

When assessing Base metrics, it should be assumed that the attacker has advancedknowledge of the target system, including general configuration and defaultdefense mechanisms (e.g., built-in firewalls, rate limits, traffic policing).For example, exploiting a vulnerability that results in repeatable,deterministic success should still be considered a Low value for AttackComplexity, independent of the attacker's knowledge or capabilities.Furthermore, target-specific attack mitigation (e.g., custom firewall filters,access lists) should instead be reflected in the Environmental metric scoringgroup.

Specific configurations should not impact any attribute contributing to the CVSSBase metric assessment , i.e., if a specific configuration is required for anattack to succeed, the vulnerable system should be assessed assuming it is inthat configuration.

Attack Vector (AV)

This metric reflects the context by which vulnerability exploitation ispossible. This metric value (and consequently the resulting severity) will belarger the more remote (logically, and physically) an attacker can be in orderto exploit the vulnerable system. The assumption is that the number of potentialattackers for a vulnerability that could be exploited from across a network islarger than the number of potential attackers that could exploit a vulnerabilityrequiring physical access to a device, and therefore warrants a greaterseverity. The list of possible values is presented in Table 1.

Table 1: Attack Vector

Assessment Guidance: When deciding between Network and Adjacent, if an attackcan be launched over a wide area network or from outside the logically adjacentadministrative network domain, use Network.

Attack Complexity (AC)

This metric captures measurable actions that must be taken by the attacker toactively evade or circumvent existing built-in security-enhancing conditionsin order to obtain a working exploit. These are conditions whose primary purposeis to increase security and/or increase exploit engineering complexity. Avulnerability exploitable without a target-specific variable has a lowercomplexity than a vulnerability that would require non-trivial customization.This metric is meant to capture security mechanisms utilized by the vulnerablesystem, and does not relate to the amount of time or attempts it would take foran attacker to succeed, e.g. a race condition. If the attacker does not takeaction to overcome these conditions, the attack will always fail.

The evasion or satisfaction of authentication mechanisms or requisites isincluded in the Privileges Required assessment and is not considered here asa factor of relevance for Attack Complexity.

Table 2: Attack Complexity

As described in Section 2.1, detailed knowledge of the vulnerable system isoutside the scope of Attack Complexity. Refer to that section for additionalguidance when scoring Attack Complexity when target-specific attack mitigationis present.

Attack Requirements (AT)

This metric captures the prerequisite deployment and execution conditions orvariables of the vulnerable system that enable the attack. These differ fromsecurity-enhancing techniques/technologies (ref Attack Complexity) as theprimary purpose of these conditions is not to explicitly mitigate attacks,but rather, emerge naturally as a consequence of the deployment and execution ofthe vulnerable system. If the attacker does not take action to overcome theseconditions, the attack may succeed only occasionally or not succeed at all.

Table 3: Attack Requirements

Privileges Required (PR)

This metric describes the level of privileges an attacker must possess priorto successfully exploiting the vulnerability. The method by which the attackerobtains privileged credentials prior to the attack (e.g., free trial accounts),is outside the scope of this metric. Generally, self-service provisionedaccounts do not constitute a privilege requirement if the attacker can grantthemselves privileges as part of the attack.

The resulting score is greatest if no privileges are required. The list ofpossible values is presented in Table 4.

Table 4: Privileges Required

Assessment Guidance: Privileges Required is usually None for hard-codedcredential vulnerabilities or vulnerabilities requiring social engineering(e.g., reflected cross-site scripting, cross-site request forgery, or fileparsing vulnerability in a PDF reader). Default credentials that have not beenchanged or are not unique across each environment should be treated similarly tohard-coded credentials.

User Interaction (UI)

This metric captures the requirement for a human user, other than the attacker,to participate in the successful compromise of the vulnerable system. Thismetric determines whether the vulnerability can be exploited solely at the willof the attacker, or whether a separate user (or user-initiated process) mustparticipate in some manner. The resulting score is greatest when no userinteraction is required. The list of possible values is presented in Table 5.

Table 5: User Interaction

Impact Metrics

The Impact metrics capture the effects of a successfully exploitedvulnerability. Analysts should constrain impacts to a reasonable, final outcomewhich they are confident an attacker is able to achieve.

Only an increase in access, privileges gained, or other negative outcome as aresult of successful exploitation should be considered when assessing the Impactmetrics of a vulnerability. For example, consider a vulnerability that requiresread-only permissions prior to being able to exploit the vulnerability. Aftersuccessful exploitation, the attacker maintains the same level of read access,and gains write access. In this case, only the Integrity impact metric should bescored, and the Confidentiality and Availability Impact metrics should be set asNone.

Note that when scoring a delta change in impact, the final impact should beused. For example, if an attacker starts with partial access to restrictedinformation (Confidentiality Low) and successful exploitation of thevulnerability results in complete loss in confidentiality (ConfidentialityHigh), then the resultant CVSS Base metric value should reference the “end game”Impact metric value (Confidentiality High).

When identifying values for the impact metrics, assessment providers need toaccount for impacts both to the Vulnerable System and impacts outside of theVulnerable System. These impacts are established by two sets of impact metrics:“Vulnerable System impact” and “Subsequent System impact”. When establishingthe boundaries for the Vulnerable System metric values, assessment providersshould use the conceptual model of a system of interest.

Formally, a system of interest for scoring a vulnerability is defined as the setof computing logic that executes in an environment with a coherent function andset of security policies. The vulnerability exists in one or more components ofsuch a system. A technology product or a solution that serves a purpose orfunction from a consumer's perspective is considered a system (e.g., a server,workstation, containerized service, etc.).

When a system provides its functionality solely to another system, or it isdesigned to be exclusively used by another system, then together they areconsidered as the system of interest for scoring. For example, a database usedsolely by a smart speaker is considered a part of that smart speaker system.Both the database and the smart speaker it serves would be considered thevulnerable system if a vulnerability in that database leads to the malfunctionof the smart speaker. When a vulnerability does not have impact outside of thevulnerable system assessment providers should leave the subsequent system impactmetrics as NONE (N).

All impacts, if any, that occur outside of the vulnerable system should bereflected in the subsequent system impact set. When assessed in theenvironmental metric group only, the subsequent system impact may, in additionto the logical systems defined for System of Interest, also include impacts tohumans. This human impact option in the environmental metric group is explainedfurther in Safety (S), below.

Confidentiality (VC/SC)

This metric measures the impact to the confidentiality of the informationmanaged by the system due to a successfully exploited vulnerability.Confidentiality refers to limiting information access and disclosure to onlyauthorized users, as well as preventing access by, or disclosure to,unauthorized ones. The resulting score is greatest when the loss to the systemis highest. The list of possible values is presented in Table 6 (for theVulnerable System) and Table 7 (when there is a Subsequent System impacted).

Table 6: Confidentiality Impact to the Vulnerable System (VC)

Table 7: Confidentiality Impact to the Subsequent System (SC)

Integrity (VI/SI)

This metric measures the impact to integrity of a successfully exploitedvulnerability. Integrity refers to the trustworthiness and veracity ofinformation. Integrity of a system is impacted when an attacker causesunauthorized modification of system data. Integrity is also impacted when asystem user can repudiate critical actions taken in the context of the system(e.g. due to insufficient logging).

The resulting score is greatest when the consequence to the system is highest.The list of possible values is presented in Table 8 (for the Vulnerable System)and Table 9 (when there is a Subsequent System impacted).

Table 8: Integrity Impact to the Vulnerable System (VI)

Table 9: Integrity Impact to the Subsequent System (SI)

Availability (VA/SA)

This metric measures the impact to the availability of the impacted systemresulting from a successfully exploited vulnerability. While the Confidentialityand Integrity impact metrics apply to the loss of confidentiality or integrityof data (e.g., information, files) used by the system, this metric refers tothe loss of availability of the impacted system itself, such as a networkedservice (e.g., web, database, email). Since availability refers to theaccessibility of information resources, attacks that consume network bandwidth,processor cycles, or disk space all impact the availability of a system. Theresulting score is greatest when the consequence to the system is highest. Thelist of possible values is presented in Table 10 (for the Vulnerable System) andTable 11 (when there is a Subsequent System impacted).

Table 10: Availability Impact to the Vulnerable System (VA)

Table 11: Availability Impact to the Subsequent System (SA)

The Threat metrics measure the current state of exploit techniques or codeavailability for a vulnerability.

Exploit Maturity (E)

This metric measures the likelihood of the vulnerability being attacked, and isbased on the current state of exploit techniques, exploit code availability, oractive, “in-the-wild” exploitation. Public availability of easy-to-use exploitcode or exploitation instructions increases the number of potential attackers byincluding those who are unskilled. Initially, real-world exploitation may onlybe theoretical. Publication of proof-of-concept exploit code, functional exploitcode, or sufficient technical details necessary to exploit the vulnerability mayfollow. Furthermore, the available exploit code or instructions may progressfrom a proof-of-concept demonstration to exploit code that is successful inexploiting the vulnerability consistently. In severe cases, it may be deliveredas the payload of a network-based worm or virus or other automated attack tools.

It is the responsibility of the CVSS consumer to populate the values of ExploitMaturity (E) based on information regarding the availability of exploitationcode/processes and the state of exploitation techniques. This information willbe referred to as “threat intelligence” throughout this document.

Operational Recommendation: Threat intelligence sources that provide ExploitMaturity information for all vulnerabilities should be preferred over those withonly partial coverage. Also, it is recommended to use multiple sources of threatintelligence as many are not comprehensive. This information should be updatedas frequently as possible and its application to CVSS assessment should beautomated.

The list of possible values is presented in Table 12. The more easily avulnerability can be exploited, the higher the vulnerability score.

Table 12: Exploit Maturity

These metrics enable the consumer analyst to customize the resulting scoredepending 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 modifiedequivalent of Base metrics and are assigned values based on the system placementwithin organizational infrastructure.

Confidentiality, Integrity, and Availability Requirements (CR, IR, AR)

These metrics enable the consumer to customize the assessment depending on theimportance of the affected IT asset to the analyst’s organization, measured interms of Confidentiality, Integrity, and Availability. That is, if an IT assetsupports a business function for which Availability is most important, theanalyst can assign a greater value to Availability metrics relative toConfidentiality and Integrity. Each Security Requirement has three possiblevalues: Low, Medium, or High, or the default value of Not Defined (X).

The full effect on the environmental score is determined by the correspondingModified Base Impact metrics. Following the concept of assuming “reasonableworst case”, in absence of explicit values, these metrics are set to the defaultvalue of Not Defined (X), which is equivalent to the metric value of High (H).

The list of possible values is presented in Table 13. For brevity, the sametable is used for all three metrics. The lower the Security Requirement, thelower the score (recall that High is considered the default).

Table 13: Security Requirements

Modified Base Metrics

These metrics enable the consumer analyst to override individual Base metricvalues based on specific characteristics of a user’s environment.Characteristics that affect Exploitability or Impact can be reflected via anappropriately modified Environmental metric value.

The full effect on the resulting score is determined by the corresponding Basemetrics as follows

• if the Modified Base Metric is Not Defined (X), the calculation of the scorewill use the value of the original Base Metrics

• If the Modified Base Metric value is defined, then for the purpose of thecalculation of the metric, the Base Metric value will be replaced by theModified Base Metric value.

Example: If a provider sets the Base Metric Privileges Required to Low (PR:L)and an analyst overrides Modified Privileges Required to High (MPR:H), then theresulting score will be calculated as if the Base Metric Privileges Requires wasset to High. Similarly, if a provider sets the Base Metric Attack Vector toNetwork (AV:N) and an analyst sets Modified Attack Vector to Physical (MAV:P),then the resulting score will be calculated as if the Base Attack Vector was setto Physical.

A special case to this rule applies to the Modified Subsequent System Integrity(MSI) and the Modified Subsequent System Availability (MSA) which can be set toan additional special value of Safety (S) which is not included in the BaseSubsequent System impact metrics. In this particular case, the special valuewill be directly used for the calculation of the score as explained in thesection 4.2.1 below.

The intent of these metrics are to define the mitigations and compensatingcontrols that are in place for a given environment. It is acceptable to use themodified metrics to represent situations that increase the resulting score. Hereare some examples:

Example 1: The default configuration of a component may require high privilegesto access a particular function. However, in the consumer analyst’s environment,administrative privileges might be granted by default without authenticating theuser. The analyst can set Privileges Required to High and Modified PrivilegesRequired to None to reflect this more serious condition in their particularenvironment.

Example 2: The default configuration for a vulnerable system may be to run alistening service with administrator privileges, for which a compromise mightgrant an attacker Confidentiality, Integrity, and Availability impacts that areall High. Yet, in the consumer analyst’s environment, that same Internet servicemight be running with reduced privileges; in that case, the ModifiedConfidentiality, Modified Integrity, and Modified Availability might each be setto Low.

Example 3: Systems and appliances located in an isolated network with no accessto or from the Internet are not able to be attacked through the Wide AreaNetwork (WAN). All vulnerabilities found on those systems may have the AttackVector (AV) values of “Network” reduced to “Adjacent”.

For brevity, only the names of the Modified Base metrics are mentioned. EachModified Environmental metric has the same values as its corresponding Basemetric, plus values of Not Defined and Safety. Not Defined is the default anduses the metric value of the associated Base metric.

4.2.1 Modified Base Metrics and Safety

When a system may have safety implications as a matter of how or where it isdeployed, it is possible that exploiting a vulnerability within that system mayhave safety impact(s) which can be represented in the Environmental Metricsgroup.

If the exploitation of a technical vulnerability (with impact to either theavailability or integrity of the vulnerable system) has the potential to impacthuman safety, the modified subsequent system impact of Safety (s) should be used(i.e., MSI:S/MSA/S).

The Safety metric value measures the impact regarding the Safety of a humanactor or participant that can be predictably injured as a result of thevulnerability being exploited. Unlike other impact metric values, Safety canonly be associated with the Subsequent System impact set and should beconsidered in addition to the N/L/H impact values for Availability and Integritymetrics.

Note: If Safety is applicable, it should be explicitly assigned even if, and inaddition to, impact values of H are already supplied for Availability andIntegrity metrics.

Safety impact is applicable when it is predictable that an exploitedvulnerability may result in injuries categorized as Marginal or worse using theIEC 61508 definitions outlined in the chart below.

Table 14: IEC 61508 Definitions

Note: Safety metric values are leveraged in both the Supplemental Metric Group(provided by the assessment providers) and the Environmental Metric Group(provided by the consumer analyst). The list of possible values is presentedbelow.

Table 15: Modified Base Metrics

A new, optional metric group called the Supplemental metric group provides newmetrics that describe and measure additional extrinsic attributes of avulnerability. While the assessment of Supplemental metrics is provisioned bythe provider, the usage and response plan of each metric within the Supplementalmetric group is determined by the consumer. This contextual information may beemployed differently in each consumer’s environment. No metric will have anyimpact on the final calculated CVSS score (e.g. CVSS-BTE). Organizations maythen assign importance and/or effective impact of each metric, orset/combination of metrics, giving them more, less, or absolutely no effect onthe final risk analysis. Metrics and values will simply convey additionalextrinsic characteristics of the vulnerability itself.

Safety (S)

Like all Supplemental Metrics, providing a value for Safety is completelyoptional. Suppliers and vendors (AKA: scoring providers) may or may not provideSafety as a Supplemental Metric as they see fit.

When a system does have an intended use or fitness of purpose aligned to safety,it is possible that exploiting a vulnerability within that system may haveSafety impact which can be represented in the Supplemental Metrics group. Lackof a Safety metric value being supplied does NOT mean that there may not be anySafety-related impacts. The possible values for the Safety Supplemental Metricare as follows:

Table 16: Safety

The Safety supplemental metric value indicates the degree of impact to theSafety of a human actor or participant that can be predictably injured as aresult of the vulnerability being exploited.

Note that Safety metrics are defined in both Environmental and Supplementalcontexts, although the vector string values differ. As a Supplemental metric,and consistent with the above table, Safety can be described with metric valuesof S:X, S:P, or S:N.

The IEC 61508 consequence categories are defined in Table 14 above (as of thiswriting).

Automatable (AU)

The “Automatable” metric captures the answer to the question ”Can an attackerautomate exploitation events for this vulnerability across multiple targets?”based on steps 1-4 of the kill chain² [Hutchins et al., 2011]. These stepsare reconnaissance, weaponization, delivery, and exploitation. If evaluated, themetric can take the values no or yes:

Table 17: Automatable

Provider Urgency (U)

Many vendors currently provide supplemental severity ratings to consumers viaproduct security advisories. Other vendors publish Qualitative Severity Ratingsfrom the CVSS Specification Document in their advisories.

To facilitate a standardized method to incorporate additional provider-suppliedassessment, an optional “pass-through” Supplemental Metric called ProviderUrgency is available.

Note: While any assessment provider along the product supply chain mayprovide a Provider Urgency rating:

Library Maintainer → OS/Distro Maintainer → Provider 1 … Provider n (PPP)→ Consumer

The Penultimate Product Provider (PPP) is best positioned to provide a directassessment of Provider Urgency.

Table 18: Provider Urgency

Recovery (R)

Recovery describes the resilience of a system to recover services, in terms ofperformance and availability, after an attack has been performed.

Table 19: Recovery

Value Density (V)

Value Density describes the resources that the attacker will gain control overwith a single exploitation event. It has two possible values, diffuse andconcentrated:

Table 20: Value Density

Vulnerability Response Effort (RE)

The intention of the Vulnerability Response Effort metric is to providesupplemental information on how difficult it is for consumers to provide aninitial response to the impact of vulnerabilities for deployed products andservices in their infrastructure. The consumer can then take this additionalinformation on effort required into consideration when applying mitigationsand/or scheduling remediation.

When calculating Vulnerability Response Effort, the effort required to deploythe quickest available response should be considered.

Table 21: Vulnerability Response Effort

For some purposes it is useful to have a textual representation of the resultingnumeric Base, Threat and Environmental scores. All CVSS scores regardless ofnomenclature can be mapped to the qualitative ratings defined in Table 22.³

Table 22: Qualitative severity rating scale

As an example, a CVSS Base Score of 5.0 has an associated severity rating ofMedium. The use of these qualitative severity ratings is optional, and there isno requirement to include them when publishing CVSS scores. They are intended tohelp organizations properly assess and prioritize their vulnerability managementprocesses.

The CVSS v4.0 vector string is a text representation of a set of CVSS metrics.It is commonly used to record or transfer CVSS metric information in a conciseand machine-readable form.

The CVSS v4.0 vector string begins with the label “CVSS:” and a numericrepresentation of the current version, “4.0”. Metric information follows in theform of a set of metrics, each preceded by a forward slash, “/”, acting as adelimiter. Each metric is a metric name in abbreviated form, a colon (“:”), andits associated metric value in abbreviated form. The abbreviated forms aredefined earlier in this specification (in parentheses after each metric name andmetric value, case sensitive), and are summarized in the table below.

A vector string must contain metrics in the order shown in Table 23, every otherordering is invalid. All Base metrics must be included in a vector string.Threat, Environmental, and Supplemental metrics are optional, and omittedmetrics are considered to have the value of Not Defined (X). Metrics with avalue of Not Defined can be explicitly included in a vector string if desired.Systems that produce or consume CVSS v4.0 vector strings must do so in thefollowing order and treat unspecified Threat, Environmental and Supplemental asNot Defined. A vector string must not include the same metric more than once.

Table 23: Base, Threat and Environmental Vectors

For example, a vulnerability with Base metric values of:

• Attack Vector: Network

• Attack Complexity: Low

• Attack Requirements: None

• Privileges Required: High

• User Interaction: None

• Vulnerable System Confidentiality: Low

• Vulnerable System Integrity: Low

• Vulnerable System Availability: None

• no Subsequent System impact (C/I/A),

• and no specified Threat or Environmental metrics would produce the followingvector:

  • CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N

• The same example with the addition of Exploit Maturity: Attackedwould produce the following vector:

  • CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:A

The following examples are valid CVSS v4.0 vectors, provided along a shortdescription:

• CVSS-BT sample vector string

  • CVSS:4.0/AV:A/AC:H/AT:P/PR:L/UI:P/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L/E:P

• CVSS-BE sample vector string

  • CVSS:4.0/AV:L/AC:H/AT:N/PR:N/UI:A/VC:N/VI:N/VA:L/SC:H/SI:H/SA:H/CR:H/IR:H/AR:M/MAV:N/MAC:L/MAT:P/MPR:L/MUI:A/MVC:N/MVI:H/MVA:L/MSC:L/MSI:S/MSA:H

• CVSS-B with Supplemental sample vector string

  • CVSS:4.0/AV:P/AC:H/AT:P/PR:L/UI:P/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L/E:A/S:P/AU:Y/R:A/V:D/RE:L/U:Red

• CVSS-BTE with Supplemental sample vector string

  • CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:U/CR:L/IR:X/AR:L/MAV:A/MAC:H/MAT:N/MPR:N/MUI:P/MVC:X/MVI:N/MVA:H/MSC:N/MSI:L/MSA:S/S:N/AU:N/R:I/V:C/RE:H/U:Green

The following vectors are invalid and are provided along a shortexplanation:

• “F” is not a valid value for “AV”

  • CVSS:4.0/AV:F/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N

• “E” metric is defined more than once

  • CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:N/SA:N/E:A/E:X

• “ui” is not a valid metric abbreviation

  • CVSS:4.0/AV:N/AC:L/AT:N/PR:N/ui:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N

• CVSS v4.0 prefix is missing

  • AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N

• Mandatory metric “VA” is missing

  • CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/SC:N/SI:N/SA:N

• Fixed ordering is not respected (CVSS-BTE with Supplemental)

  • CVSS:4.0/AC:L/AV:N/PR:H/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/CR:L/IR:X/AR:L/RE:H/MAV:A/MAC:H/MAT:N/MPR:N/MUI:P/AT:N/MVC:X/MVI:N/MVA:H/MSC:N/MSI:L/MSA:S/E:U/S:N/AU:N/R:I/V:C/U:Green

The CVSS v4.0 scoring methodologies are described in the sub-sections below.

New Scoring System Development

The scoring system development for CVSS v4.0 consisted of the following broadsteps:

1. Use metric groups to gather the 15 million CVSS-BTE vectors into 270disjoint equivalence sets under a relation of comparable qualitativeseverity

2. Solicit experts to compare vectors representing each equivalence set

3. Use the expert comparison data to calculate an order of vectors from leastsevere to most severe

4. Solicit expert opinion to decide which equivalence set of vectors p in theordering of vectors represents the boundary between qualitative severityscores to be backwards compatible with qualitative severity score boundariesfrom CVSS v3.x

5. Compress the equivalence set of vectors in each qualitative severity bininto the number of available scores in that bin (for example, 9.0 to 10.0for critical, 7.0 to 8.9 for high, etc.)

6. Create a small score modification factor that adjusts the scores of vectorswithin a qualitatively equivalent set of vectors so that a change of anymetric value results in a resulting score change, where possible. The intentis that the score change is not larger than the uncertainty in the rankingof the vector groups as collected from the expert comparison data in step 2.This is further discussed in section 8.2 below.

Additional information about the new approach to scoring calculation developedin CVSS v4.0 can be found in Section 2.5 of the CVSS v4.0 User Guide.

CVSS v4.0 Scoring using MacroVectors and Interpolation

The CVSS v4.0 formula provides a mathematical approximation of all possiblemetric combinations ranked in order of severity where vectors are clustered insets called MacroVectors. A MacroVector is one of the sets of CVSS vectorsthat the expert evaluation process described in section 8.1 (steps 1-3)determined to be of comparable qualitative severity. Each MacroVectorconstitutes an equivalence class⁴ from such a qualitative perspective.

The score of a MacroVector is defined by a lookup table as defined by thesubject matter expert process mentioned above and is specified in Section 8.3.The score of a vector within each MacroVector is defined by interpolation.

To determine a preliminary set of relevant MacroVectors, The SIG determined thefollowing preliminary metrics subgroups. Additional EQs or levels can bedetermined for a finer resolution.

• EQ1 → AV/PR/UI with 3 levels specified in Table 24

• EQ2 → AC/AT with 2 levels specified in Table 25

• EQ3 → VC/VI/VA with 3 levels specified in Table 26

• EQ4 → SC/SI/SA with 3 levels specified in Table 27

• EQ5 → E with 3 levels specified in Table 28

• EQ6 → VC/VI/VA+CR/CI/CA with 2 levels specified in Table 29

Intuitively, each level of a metric subgroup corresponds to a different severitylevel with zero being the most severe and one or two being the least severe.

Since EQ3 and EQ6 are not independent they must be considered together

• EQ3+EQ6 → determines 5 levels specified in Table 30

A highest severity vector of a MacroVector is a vector that

• Satisfies the boolean conditions for membership into a MacroVector

• No other vector in the MacroVector has a higher severity in at least ametric

The lowest severity vector of a MacroVector is determined in a similar way.

One MacroVector might have more than one highest severity vector and more thanone lowest severity vector. For example the MacroVectors which satisfy EQ1 atlevel 1 shown in Table 24 have as highest severity vectors all vectors with

• AV:A/PR:N/UI:N or AV:N/PR:L/UI:N or AV:N/PR:N:/UI:P

as they all satisfy the constraints specified in Table 24.

• (AV:N or PR:N or UI:N) and

  • as we have AV:A/PR:N/UI:N, AV:N/PR:L/UI:N,AV:N/PR:N:/UI:P

• not (AV:N and PR:N and UI:N) and

  • as we have AV:A/PR:N/UI:N, AV:N/PR:L/UI:N, AV:N/PR:N:/UI:P

• not AV:P

  • as we have AV:A/PR:N/UI:N, AV:N/PR:L/UI:N, AV:N/PR:N:/UI:P

Table 24: EQ1 - MacroVectors

Table 25: EQ2 - MacroVectors

Table 26: EQ3 - MacroVectors

Table 27: EQ4 - MacroVectors

If MSI=X or MSA=X they will default to the corresponding value of SI and SAaccording to the rules of Modified Base Metrics in section 4.2 (See Table 15).So if there are no modified base metrics, the highest value that EQ4 can reachis 1.

Table 28: EQ5 - MacroVectors

If E=X it will default to the worst case (i.e., E=A).

Table 29: EQ6 - MacroVectors

If CR=X, IR=X or AR=X they will default to the worst case (i.e., CR=H, IR=H andAR=H).

Table 30: Joint EQ3+EQ6 - MacroVectors

Given two vectors the severity distance between them is the number ofconsecutive stepwise changes in individual metrics given Section 2 orderingneeded to transform one vector into the other.

For example a Vector with VC:H/VI:H/VA:H has a severity distance of 3 from avector that contains VC:H/VI:L/VA:N and is otherwise identical

• VC:H/VI:H/VA:H → VC:H/VI:L/VA:H → VC:H/VI:L/VA:L →VC:H/VI:L/VA:N

The depth of a MacroVector is the maximum severity distance between thehighest severity vector(s) and the lowest severity vector(s) of the MacroVector.

The notion of depth can be better understood by a graphical visualization. Forexample consider EQ3=2 which is defined in Table 26 as all metrics values suchthat not (VC=H or VI=H or VA=H). Figure 2 shows all metric values of VC, VI, andVA in that MacroVector starting from the highest severity vector(VC:L/VI:L/VA:L) to the lowest severity vector (VC:N/VI:N/VA:N).

Figure 2: Vectors included MacroVector with EQ3=2 and everything else fixed.

The highest severity vector of a MacroVector is always assigned the score of theMacroVector from the cvss_lookup.js file within the CVSS v4.0 calculatorreference implementation available on GitHub (see Section 8.3).

A vector within a MacroVector is assigned the score of the highest severityvector in the MacroVector minus the mean proportional distance from theMacroVectors below it.

This is obtained by the following algorithm.

1. For each of the EQs

   1. The maximal scoring difference is determined as the difference betweenthe current MacroVector and the lower MacroVector

      1. if there is no lower MacroVector the available distance is set toNaN and then ignored in the further calculations

   2. The severity distance of the to-be scored vector from a highest severityvector in the same MacroVector is determined

   3. The proportion of the distance is determined by dividing the severitydistance of the to-be-scored vector by the depth of the MacroVector

   4. The maximal scoring difference is multiplied by the proportion ofdistance

2. The mean of the above computed proportional distances is computed

3. The score of the vector is the score of the MacroVector (i.e. the score ofthe highest severity vector) minus the mean distance so computed. This scoreis rounded to one decimal place.

Scores of all MacroVectors

A complete list of all MacroVectors and associated scores can be found in thecvss_lookup.js file within the CVSS v4.0 calculator reference implementationavailable on GitHub:

https://github.com/FIRSTdotorg/cvss-v4-calculator/blob/main/cvss_lookup.js

FIRST sincerely recognizes the contributions of the following CVSS SpecialInterest Group (SIG) members, listed in alphabetical order by last name:

• Abdulhamid Adebayo, IBM
• Srividya Ananth, National Institute of Standards and Technology (NIST)
• Chandan BN, Palo Alto Networks
• Feng Cao, Oracle
• Francesco Casotto, Cisco
• Matthew Coles, Dell Technologies
• Khushali Dalal, Juniper Networks
• Giorgio Di Tizio, University of Trento
• Dave Dugal, Juniper Networks
• Karan Dwivedi, Google
• Ben Edwards, Cyentia
• Troy Fridley, Acuity Brands
• Jeff Heller, Sandia National Laboratories
• Adrian Henrick
• Allen Householder, CERT/CC
• Miguel Hummel, Citi
• Fabrice Kah, Schneider Electric
• Stav Kaufman, Skybox Security
• Austin Kimbrell, Red Hat
• Toby Kohlenberg, Intel
• Jim Kohli, GE Healthcare
• Stanislav Kontar, Red Hat
• Milind Kulkarni, Ericsson
• Arkadeep Kundu, Cisco
• Nick Leali, Cisco
• Fábio Olivé Leite, Red Hat
• Angela Lindberg, SAP
• Kumar Mangipudi
• Art Manion, ANALYGENCE Labs
• Fabio Massacci, University of Trento and Vrije Universiteit Amsterdam
• Peter Mell, National Institute of Standards and Technology (NIST)
• Bruce Monroe, Intel
• Vivek Nair, Microsoft
• Phillip Nordwall, Dell Technologies
• Margaux Pagano, Citi
• Wilfried Pascault, CERT Orange Cyberdefense
• Francisco Luis de Andres Perez, IriusRisk
• Diana Prusova, Accenture Security
• Marián Rehák, Red Hat
• Dale Rich, Black & Veatch
• Melinda Rosario
• Zach Shue, Kiewit
• Daniel Sommerfeld, Microsoft
• Jonathan Spring, Cybersecurity and Infrastructure Security Agency (CISA)
• Janane Suresh, Oracle
• Masato Tereada
• Matt Tesauro
• Lucas Tesson
• Christopher Turner, National Institute of Standards and Technology (NIST)
• Laurie Tyzenhaus, CERT/CC
• Akshat Vaid, Juniper Networks
• Richard Wilkins, Phoenix Technologies, Inc.

FIRST would also like to thank Grace Staley from CAPS, LLC. for her tirelesswork facilitating the CVSS SIG meetings.

CVSS v4.0 main page - https://www.first.org/cvss/v4-0

The main web page for all CVSS resources, including the most recent version ofthe CVSS standard.

CVSS v4.0 Specification Document -https://www.first.org/cvss/v4-0/specification-document

The latest revision of this document, defining the metrics, formulas,qualitative rating scale and vector string.

CVSS v4.0 User Guide - https://www.first.org/cvss/v4-0/user-guide

A companion to the Specification, the User Guide includes further discussion ofthe CVSS standard including particular use cases, guidelines on scoring, scoringrubrics, and a glossary of the terms used in the Specification and User Guidedocuments.

CVSS v4.0 Examples Document - https://www.first.org/cvss/v4-0/examples

Includes scores of public vulnerabilities and explanations of why particularmetric values were chosen.

CVSS v4.0 Calculator - https://www.first.org/cvss/calculator/v4-0

A reference implementation of the CVSS standard that can be used for generatingscores. The underlying code is documented and can be used as part of otherimplementations.

JSON and XML Schemas - https://www.first.org/cvss/data-representations

Data representations for CVSS metrics, scores and vector strings in JSON Schemaand XML Schema Definition (XSD) representations. These can be used to store andtransfer CVSS information in defined JSON and XML formats.