CVSS 4.0 Calculator
The CVSS 4.0 calculator scores a vulnerability from the metric values you choose and returns the score, its severity rating and the vector string. CVSS v4.0 has no single closed formula: the metrics are grouped into six equivalence sets (EQ1 to EQ6), which form a six-digit MacroVector; FIRST's lookup table gives that MacroVector a score, and the score is then lowered by an interpolation that depends on how far your vector is from the most severe vector in its set.
Base, Threat and Environmental values are always used in a v4.0 score; metrics left at Not Defined take their default values. The Supplemental metrics never change the score. The result is labelled CVSS-B, CVSS-BT, CVSS-BE or CVSS-BTE so readers know which metric groups were used.
CVSS v4.0 score 9.3, Critical, CVSS-B
- CVSS-B
- 9.3
- MacroVector
- 000200
Load a worked example
The vulnerable system is bound to the network stack and the set of possible attackers extends beyond the other options listed below, up to and…
The attacker must take no measurable action to exploit the vulnerability.
The successful attack does not depend on the deployment and execution conditions of the vulnerable system.
The attacker is unauthenticated prior to attack, and therefore does not require any access to settings or files of the vulnerable system to carry…
The vulnerable system can be exploited without interaction from any human user, other than the attacker.
There is a total loss of confidentiality, resulting in all information within the Vulnerable System being divulged to the attacker.
There is a total loss of integrity, or a complete loss of protection.
There is a total loss of availability, resulting in the attacker being able to fully deny access to resources in the Vulnerable System; this loss is…
There is no loss of confidentiality within the Subsequent System or all confidentiality impact is constrained to the Vulnerable System.
There is no loss of integrity within the Subsequent System or all integrity impact is constrained to the Vulnerable System.
There is no impact to availability within the Subsequent System or all availability impact is constrained to the Vulnerable System.
Reliable threat intelligence is not available to determine Exploit Maturity characteristics.
This is the default value.
This is the default value.
This is the default value.
Not Defined: the corresponding Base metric value is used (this is the default).
Not Defined: the corresponding Base metric value is used (this is the default).
Not Defined: the corresponding Base metric value is used (this is the default).
Not Defined: the corresponding Base metric value is used (this is the default).
Not Defined: the corresponding Base metric value is used (this is the default).
Not Defined: the corresponding Base metric value is used (this is the default).
Not Defined: the corresponding Base metric value is used (this is the default).
Not Defined: the corresponding Base metric value is used (this is the default).
Not Defined: the corresponding Base metric value is used (this is the default).
Not Defined: the corresponding Base metric value is used (this is the default).
Not Defined: the corresponding Base metric value is used (this is the default).
The metric has not been evaluated.
The metric has not been evaluated.
The metric has not been evaluated.
The metric has not been evaluated.
The metric has not been evaluated.
The metric has not been evaluated.
How this score was computed
Result
- Score to publish
9.3 (CVSS-B)CVSS v4.0 always considers Base, Threat and Environmental values; metrics left at Not Defined use their default values, so every score is complete.
Effective metrics
- Values used for scoring
AV:N AC:L AT:N PR:N UI:N VC:H VI:H VA:H SC:N SI:N SA:N E:A CR:H IR:H AR:HA defined Modified metric replaces its Base metric; Exploit Maturity X is treated as Attacked (A); Security Requirements X are treated as High (H).
MacroVector (equivalence sets)
- EQ1
0AV:N and PR:N and UI:N - EQ2
0AC:L and AT:N - EQ3
0VC:H and VI:H - EQ4
2no Safety, and none of SC, SI, SA is H - EQ5
0E:A (Not Defined counts as Attacked) - EQ6
0(CR:H and VC:H) or (IR:H and VI:H) or (AR:H and VA:H) - MacroVector
000200The six EQ levels concatenated; this is the key into FIRST’s lookup table of 270 expert-ranked MacroVector scores.
Lookup and interpolation
- MacroVector score (lookup)
9.3The table value for the whole equivalence set; the vector is then moved down within its set by how far it is from the most severe vector of the set. - Most severe vector of the set used
AV:N/PR:N/UI:N/AC:L/AT:N/VC:H/VI:H/VA:H/CR:H/IR:H/AR:H/SC:L/SI:L/SA:L/E:A/First composed max vector that is no more severe than the vector being scored. - EQ1 next-lower MacroVector
100200 scores 8.7available 0.6; severity distance 0 of max 0.1; share 0 - EQ2 next-lower MacroVector
010200 scores 9.2available 0.1; severity distance 0 of max 0.1; share 0 - EQ3+EQ6 next-lower MacroVector
000201 scores 9.0available 0.3; severity distance 0 of max 0.7; share 0 - EQ4 next-lower MacroVector
none (ignored) - EQ5 next-lower MacroVector
000210 scores 8.9available 0.4; severity distance 0 of max 0 (EQ5 contributes 0 by design); share 0 - Mean of the shares
sum of shares / number of lower MacroVectors that exist0 (over 4) - Score
round_to_1_decimal(lookup − mean)round(9.3 − 0) = round(9.3) = 9.3
Nomenclature
- CVSS-B (Base only)
9.3
Scoring runs in your browser; nothing you enter is uploaded. Independent implementation of the FIRST.org CVSS v4.0 specification; CVSS is owned by FIRST.org, Inc. Severity scale: None 0.0, Low 0.1–3.9, Medium 4.0–6.9, High 7.0–8.9, Critical 9.0–10.0.
TL;DRWhat this calculator does
5 points
- Four metric groups: Base, Threat (Exploit Maturity only), Environmental and Supplemental. Supplemental never changes the score.
- Score = MacroVector lookup (FIRST's table) minus an interpolated severity distance, rounded to one decimal place.
- Not Defined defaults: Exploit Maturity counts as Attacked and each Security Requirement counts as High.
- v4.0 vectors must list metrics in the specification's order, with every Base metric present and no duplicates; names and values are case sensitive.
- Severity scale: None 0.0, Low 0.1 to 3.9, Medium 4.0 to 6.9, High 7.0 to 8.9 and Critical 9.0 to 10.0.
How the CVSS 4.0 score is computed
CVSS v4.0 has no closed-form equation. The calculator follows the specification and FIRST's reference implementation:
- Resolve the effective metrics: a defined Modified metric replaces its Base metric; Exploit Maturity Not Defined counts as Attacked; each Security Requirement Not Defined counts as High.
- If every impact metric (VC, VI, VA, SC, SI, SA) is None after that, the score is 0.0.
- Assign each of six equivalence sets a level: EQ1 from AV, PR and UI; EQ2 from AC and AT; EQ3 from VC, VI and VA; EQ4 from SC, SI, SA and Safety; EQ5 from Exploit Maturity; EQ6 from the Security Requirements paired with VC, VI and VA. Together they form the six-digit MacroVector.
- Look up the MacroVector's score in FIRST's table.
- For each equivalence set that has a lower MacroVector, take the score gap to it and scale it by how far your vector is from the most severe vector of the set; average these shares and subtract the mean from the lookup score.
- Round to one decimal place (and keep the result between 0 and 10).
The step-by-step values for your vector are in “How this score was computed” under the calculator. The algorithm and lookup data are by FIRST, Red Hat and contributors (BSD-2-Clause).
CVSS 4.0 metrics explained
Descriptions are excerpted from the CVSS v4.0 Specification Document. Each metric has a vector abbreviation (in brackets) that appears in the vector string.
Base metrics · 11 metrics
Intrinsic characteristics of the vulnerability. Impact is split into the Vulnerable System and any Subsequent System.
Attack Vector (AV)
This metric reflects the context by which vulnerability exploitation is possible. This metric value (and consequently the resulting severity) will be larger the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable system.
- Network (AV:N) — The vulnerable system is bound to the network stack and the set of possible attackers extends beyond the other options listed below, up to and including the entire Internet. Such a vulnerability is often termed “remotely exploitable” and can be thought of as an attack being exploitable at the protocol level one or more network hops away (e.g., across one or more routers).
- Adjacent (AV:A) — The vulnerable system is bound to a protocol stack, but the attack is limited at the protocol level to a logically adjacent topology. This can mean an attack must be launched from the same shared proximity (e.g., Bluetooth, NFC, or IEEE 802.11) or logical network (e.g., local IP subnet), or from within a secure or otherwise limited administrative domain (e.g., MPLS, secure VPN within an administrative network zone).
- Local (AV:L) — The vulnerable system is not bound to the network stack and the attacker’s path is via read/write/execute capabilities. Either: the attacker exploits the vulnerability by accessing the target system locally (e.g., keyboard, console), or through terminal emulation (e.g., SSH); or the attacker relies on User Interaction by another person to perform actions required to exploit the vulnerability (e.g., using social engineering techniques to trick a legitimate user into opening a malicious document).
- Physical (AV:P) — The attack requires the attacker to physically touch or manipulate the vulnerable system. Physical interaction may be brief (e.g., evil maid attack) or persistent. An example of such an attack is a cold boot attack in which an attacker gains access to disk encryption keys after physically accessing the target system. Other examples include peripheral attacks via FireWire/USB Direct Memory Access (DMA).
Attack Complexity (AC)
This metric captures measurable actions that must be taken by the attacker to actively evade or circumvent existing built-in security-enhancing conditions in order to obtain a working exploit. These are conditions whose primary purpose is to increase security and/or increase exploit engineering complexity.
- Low (AC:L) — The attacker must take no measurable action to exploit the vulnerability. The attack requires no target-specific circumvention to exploit the vulnerability. An attacker can expect repeatable success against the vulnerable system.
- High (AC:H) — The successful attack depends on the evasion or circumvention of security-enhancing techniques in place that would otherwise hinder the attack. These include: Evasion of exploit mitigation techniques. The attacker must have additional methods available to bypass security measures in place. For example, circumvention of address space randomization (ASLR) or data execution prevention (DEP) must be performed for the attack to be successful. Obtaining target-specific secrets.
Attack Requirements (AT)
This metric captures the prerequisite deployment and execution conditions or variables of the vulnerable system that enable the attack. These differ from security-enhancing techniques/technologies (ref Attack Complexity) as the primary purpose of these conditions is not to explicitly mitigate attacks, but rather, emerge naturally as a consequence of the deployment and execution of the vulnerable system.
- None (AT:N) — The successful attack does not depend on the deployment and execution conditions of the vulnerable system. The attacker can expect to be able to reach the vulnerability and execute the exploit under all or most instances of the vulnerability.
- Present (AT:P) — The successful attack depends on the presence of specific deployment and execution conditions of the vulnerable system that enable the attack. These include: A race condition must be won to successfully exploit the vulnerability. The successfulness of the attack is conditioned on execution conditions that are not under full control of the attacker. The attack may need to be launched multiple times against a single target before being successful. Network injection.
Privileges Required (PR)
This metric describes the level of privileges an attacker must possess prior to successfully exploiting the vulnerability. The method by which the attacker obtains privileged credentials prior to the attack (e.g., free trial accounts), is outside the scope of this metric.
- None (PR:N) — The attacker is unauthenticated prior to attack, and therefore does not require any access to settings or files of the vulnerable system to carry out an attack.
- Low (PR:L) — The attacker requires privileges that provide basic capabilities that are typically limited to settings and resources owned by a single low-privileged user. Alternatively, an attacker with Low privileges has the ability to access only non-sensitive resources.
- High (PR:H) — The attacker requires privileges that provide significant (e.g., administrative) control over the vulnerable system allowing full access to the vulnerable system’s settings and files.
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. This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner.
- None (UI:N) — The vulnerable system can be exploited without interaction from any human user, other than the attacker. Examples include: a remote attacker is able to send packets to a target system a locally authenticated attacker executes code to elevate privileges
- Passive (UI:P) — Successful exploitation of this vulnerability requires limited interaction by the targeted user with the vulnerable system and the attacker’s payload. These interactions would be considered involuntary and do not require that the user actively subvert protections built into the vulnerable system.
- Active (UI:A) — Successful exploitation of this vulnerability requires a targeted user to perform specific, conscious interactions with the vulnerable system and the attacker’s payload, or the user’s interactions would actively subvert protection mechanisms which would lead to exploitation of the vulnerability. Examples include: importing a file into a vulnerable system in a specific manner placing files into a specific directory prior to executing code submitting a specific string into a web application (e.g.
Confidentiality (Vulnerable System) (VC)
This metric measures the impact to the confidentiality of the information managed by the system due to a successfully exploited vulnerability. The resulting score is greatest when the loss to the system is highest.
- High (VC:H) — There is a total loss of confidentiality, resulting in all information within the Vulnerable System 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.
- Low (VC:L) — There is some loss of confidentiality. Access to some restricted information is obtained, but the attacker does not have control over what information is obtained, or the amount or kind of loss is limited. The information disclosure does not cause a direct, serious loss to the Vulnerable System.
- None (VC:N) — There is no loss of confidentiality within the Vulnerable System.
Integrity (Vulnerable System) (VI)
This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of a system is impacted when an attacker causes unauthorized modification of system data.
- High (VI:H) — There is a total loss of integrity, or a complete loss of protection. For example, the attacker is able to modify any/all files protected by the Vulnerable System. Alternatively, only some files can be modified, but malicious modification would present a direct, serious consequence to the Vulnerable System.
- Low (VI:L) — Modification of data is possible, but the attacker does not have control over the consequence of a modification, or the amount of modification is limited. The data modification does not have a direct, serious impact to the Vulnerable System.
- None (VI:N) — There is no loss of integrity within the Vulnerable System.
Availability (Vulnerable System) (VA)
This metric measures the impact to the availability of the impacted system resulting from a successfully exploited vulnerability. It refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email).
- High (VA:H) — There is a total loss of availability, resulting in the attacker being able to fully deny access to resources in the Vulnerable System; this loss is either sustained (while the attacker continues to deliver the attack) or persistent (the condition persists even after the attack has completed).
- Low (VA:L) — Performance is reduced or there are interruptions in resource availability. Even if repeated exploitation of the vulnerability is possible, the attacker does not have the ability to completely deny service to legitimate users. The resources in the Vulnerable System 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 Vulnerable System.
- None (VA:N) — There is no impact to availability within the Vulnerable System.
Confidentiality (Subsequent System) (SC)
Confidentiality impact to systems other than the vulnerable system. If a vulnerability does not impact anything outside the vulnerable system, leave the subsequent system impact metrics as None (N).
- High (SC:H) — There is a total loss of confidentiality, resulting in all resources within the Subsequent System 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.
- Low (SC:L) — There is some loss of confidentiality. Access to some restricted information is obtained, but the attacker does not have control over what information is obtained, or the amount or kind of loss is limited. The information disclosure does not cause a direct, serious loss to the Subsequent System.
- None (SC:N) — There is no loss of confidentiality within the Subsequent System or all confidentiality impact is constrained to the Vulnerable System.
Integrity (Subsequent System) (SI)
Integrity impact to systems other than the vulnerable system. If a vulnerability does not impact anything outside the vulnerable system, leave the subsequent system impact metrics as None (N).
- High (SI:H) — There is a total loss of integrity, or a complete loss of protection. For example, the attacker is able to modify any/all files protected by the Subsequent System. Alternatively, only some files can be modified, but malicious modification would present a direct, serious consequence to the Subsequent System.
- Low (SI:L) — Modification of data is possible, but the attacker does not have control over the consequence of a modification, or the amount of modification is limited. The data modification does not have a direct, serious impact to the Subsequent System.
- None (SI:N) — There is no loss of integrity within the Subsequent System or all integrity impact is constrained to the Vulnerable System.
Availability (Subsequent System) (SA)
Availability impact to systems other than the vulnerable system. If a vulnerability does not impact anything outside the vulnerable system, leave the subsequent system impact metrics as None (N).
- High (SA:H) — There is a total loss of availability, resulting in the attacker being able to fully deny access to resources in the Subsequent System; this loss is either sustained (while the attacker continues to deliver the attack) or persistent (the condition persists even after the attack has completed).
- Low (SA:L) — Performance is reduced or there are interruptions in resource availability. Even if repeated exploitation of the vulnerability is possible, the attacker does not have the ability to completely deny service to legitimate users. The resources in the Subsequent System 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 Subsequent System.
- None (SA:N) — There is no impact to availability within the Subsequent System or all availability impact is constrained to the Vulnerable System.
Threat metrics · 1 metrics
Exploit Maturity: the current state of exploit techniques and code. Not Defined is scored as Attacked.
Exploit Maturity (E)
This metric measures the likelihood of the vulnerability being attacked, and is 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 or exploitation instructions increases the number of potential attackers by including those who are unskilled.
- Not Defined (E:X) — Reliable threat intelligence is not available to determine Exploit Maturity characteristics. This is the default value and is equivalent to Attacked (A) for the purposes of the calculation of the score by assuming the worst case.
- Attacked (E:A) — Based on available threat intelligence either of the following must apply: (1) Attacks targeting this vulnerability (attempted or successful) have been reported (2) Solutions to simplify attempts to exploit the vulnerability are publicly or privately available (such as exploit toolkits)
- Proof-of-Concept (E:P) — Based on available threat intelligence each of the following must apply: Proof-of-concept exploit code is publicly available No knowledge of reported attempts to exploit this vulnerability No knowledge of publicly available solutions used to simplify attempts to exploit the vulnerability (i.e., the “Attacked” value does not apply)
- Unreported (E:U) — Based on available threat intelligence each of the following must apply: No knowledge of publicly available proof-of-concept exploit code No knowledge of reported attempts to exploit this vulnerability No knowledge of publicly available solutions used to simplify attempts to exploit the vulnerability (i.e., neither the “POC” nor “Attacked” values apply)
Environmental metrics · 14 metrics
Security Requirements for your asset and Modified Base metrics that override the Base values. Not Defined requirements are scored as High.
Confidentiality Requirement (CR)
These metrics enable the consumer to customize the assessment depending on the importance of the affected IT asset to the analyst’s organization, measured in terms of Confidentiality, Integrity, and Availability.
- Not Defined (CR:X) — This is the default value. Assigning this value indicates there is insufficient information to choose one of the other values. This has the same effect as assigning High as the worst case.
- High (CR:H) — Loss of confidentiality is likely to have a catastrophic adverse effect on the organization or individuals associated with the organization (e.g., employees, customers).
- Medium (CR:M) — Loss of confidentiality is likely to have a serious adverse effect on the organization or individuals associated with the organization (e.g., employees, customers).
- Low (CR:L) — Loss of confidentiality is likely to have only a limited adverse effect on the organization or individuals associated with the organization (e.g., employees, customers).
Integrity Requirement (IR)
These metrics enable the consumer to customize the assessment depending on the importance of the affected IT asset to the analyst’s organization, measured in terms of Confidentiality, Integrity, and Availability.
- Not Defined (IR:X) — This is the default value. Assigning this value indicates there is insufficient information to choose one of the other values. This has the same effect as assigning High as the worst case.
- High (IR:H) — Loss of integrity is likely to have a catastrophic adverse effect on the organization or individuals associated with the organization (e.g., employees, customers).
- Medium (IR:M) — Loss of integrity is likely to have a serious adverse effect on the organization or individuals associated with the organization (e.g., employees, customers).
- Low (IR:L) — Loss of integrity is likely to have only a limited adverse effect on the organization or individuals associated with the organization (e.g., employees, customers).
Availability Requirement (AR)
These metrics enable the consumer to customize the assessment depending on the importance of the affected IT asset to the analyst’s organization, measured in terms of Confidentiality, Integrity, and Availability.
- Not Defined (AR:X) — This is the default value. Assigning this value indicates there is insufficient information to choose one of the other values. This has the same effect as assigning High as the worst case.
- High (AR:H) — Loss of availability is likely to have a catastrophic adverse effect on the organization or individuals associated with the organization (e.g., employees, customers).
- Medium (AR:M) — Loss of availability is likely to have a serious adverse effect on the organization or individuals associated with the organization (e.g., employees, customers).
- Low (AR:L) — Loss of availability is likely to have only a limited adverse effect on the organization or individuals associated with the organization (e.g., employees, customers).
Modified Attack Vector (MAV)
Modified version of the Base metric "Attack Vector". It lets you override the Base value for your own environment. This metric reflects the context by which vulnerability exploitation is possible. This metric value (and consequently the resulting severity) will be larger the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable system.
- Not Defined (MAV:X) — Not Defined: the corresponding Base metric value is used (this is the default).
- Network (MAV:N) — The vulnerable system is bound to the network stack and the set of possible attackers extends beyond the other options listed below, up to and including the entire Internet. Such a vulnerability is often termed “remotely exploitable” and can be thought of as an attack being exploitable at the protocol level one or more network hops away (e.g., across one or more routers).
- Adjacent (MAV:A) — The vulnerable system is bound to a protocol stack, but the attack is limited at the protocol level to a logically adjacent topology. This can mean an attack must be launched from the same shared proximity (e.g., Bluetooth, NFC, or IEEE 802.11) or logical network (e.g., local IP subnet), or from within a secure or otherwise limited administrative domain (e.g., MPLS, secure VPN within an administrative network zone).
- Local (MAV:L) — The vulnerable system is not bound to the network stack and the attacker’s path is via read/write/execute capabilities. Either: the attacker exploits the vulnerability by accessing the target system locally (e.g., keyboard, console), or through terminal emulation (e.g., SSH); or the attacker relies on User Interaction by another person to perform actions required to exploit the vulnerability (e.g., using social engineering techniques to trick a legitimate user into opening a malicious document).
- Physical (MAV:P) — The attack requires the attacker to physically touch or manipulate the vulnerable system. Physical interaction may be brief (e.g., evil maid attack) or persistent. An example of such an attack is a cold boot attack in which an attacker gains access to disk encryption keys after physically accessing the target system. Other examples include peripheral attacks via FireWire/USB Direct Memory Access (DMA).
Modified Attack Complexity (MAC)
Modified version of the Base metric "Attack Complexity". It lets you override the Base value for your own environment. This metric captures measurable actions that must be taken by the attacker to actively evade or circumvent existing built-in security-enhancing conditions in order to obtain a working exploit. These are conditions whose primary purpose is to increase security and/or increase exploit engineering complexity.
- Not Defined (MAC:X) — Not Defined: the corresponding Base metric value is used (this is the default).
- Low (MAC:L) — The attacker must take no measurable action to exploit the vulnerability. The attack requires no target-specific circumvention to exploit the vulnerability. An attacker can expect repeatable success against the vulnerable system.
- High (MAC:H) — The successful attack depends on the evasion or circumvention of security-enhancing techniques in place that would otherwise hinder the attack. These include: Evasion of exploit mitigation techniques. The attacker must have additional methods available to bypass security measures in place. For example, circumvention of address space randomization (ASLR) or data execution prevention (DEP) must be performed for the attack to be successful. Obtaining target-specific secrets.
Modified Attack Requirements (MAT)
Modified version of the Base metric "Attack Requirements". It lets you override the Base value for your own environment. This metric captures the prerequisite deployment and execution conditions or variables of the vulnerable system that enable the attack. These differ from security-enhancing techniques/technologies (ref Attack Complexity) as the primary purpose of these conditions is not to explicitly mitigate attacks, but rather, emerge naturally as a consequence of the deployment and execution of the vulnerable system.
- Not Defined (MAT:X) — Not Defined: the corresponding Base metric value is used (this is the default).
- None (MAT:N) — The successful attack does not depend on the deployment and execution conditions of the vulnerable system. The attacker can expect to be able to reach the vulnerability and execute the exploit under all or most instances of the vulnerability.
- Present (MAT:P) — The successful attack depends on the presence of specific deployment and execution conditions of the vulnerable system that enable the attack. These include: A race condition must be won to successfully exploit the vulnerability. The successfulness of the attack is conditioned on execution conditions that are not under full control of the attacker. The attack may need to be launched multiple times against a single target before being successful. Network injection.
Modified Privileges Required (MPR)
Modified version of the Base metric "Privileges Required". It lets you override the Base value for your own environment. This metric describes the level of privileges an attacker must possess prior to successfully exploiting the vulnerability. The method by which the attacker obtains privileged credentials prior to the attack (e.g., free trial accounts), is outside the scope of this metric.
- Not Defined (MPR:X) — Not Defined: the corresponding Base metric value is used (this is the default).
- None (MPR:N) — The attacker is unauthenticated prior to attack, and therefore does not require any access to settings or files of the vulnerable system to carry out an attack.
- Low (MPR:L) — The attacker requires privileges that provide basic capabilities that are typically limited to settings and resources owned by a single low-privileged user. Alternatively, an attacker with Low privileges has the ability to access only non-sensitive resources.
- High (MPR:H) — The attacker requires privileges that provide significant (e.g., administrative) control over the vulnerable system allowing full access to the vulnerable system’s settings and files.
Modified User Interaction (MUI)
Modified version of the Base metric "User Interaction". It lets you override the Base value for your own environment. This metric captures the requirement for a human user, other than the attacker, to participate in the successful compromise of the vulnerable system. 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.
- Not Defined (MUI:X) — Not Defined: the corresponding Base metric value is used (this is the default).
- None (MUI:N) — The vulnerable system can be exploited without interaction from any human user, other than the attacker. Examples include: a remote attacker is able to send packets to a target system a locally authenticated attacker executes code to elevate privileges
- Passive (MUI:P) — Successful exploitation of this vulnerability requires limited interaction by the targeted user with the vulnerable system and the attacker’s payload. These interactions would be considered involuntary and do not require that the user actively subvert protections built into the vulnerable system.
- Active (MUI:A) — Successful exploitation of this vulnerability requires a targeted user to perform specific, conscious interactions with the vulnerable system and the attacker’s payload, or the user’s interactions would actively subvert protection mechanisms which would lead to exploitation of the vulnerability. Examples include: importing a file into a vulnerable system in a specific manner placing files into a specific directory prior to executing code submitting a specific string into a web application (e.g.
Modified Confidentiality (Vulnerable System) (MVC)
Modified version of the Base metric "Confidentiality (Vulnerable System)". It lets you override the Base value for your own environment. This metric measures the impact to the confidentiality of the information managed by the system due to a successfully exploited vulnerability. The resulting score is greatest when the loss to the system is highest.
- Not Defined (MVC:X) — Not Defined: the corresponding Base metric value is used (this is the default).
- High (MVC:H) — There is a total loss of confidentiality, resulting in all information within the Vulnerable System 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.
- Low (MVC:L) — There is some loss of confidentiality. Access to some restricted information is obtained, but the attacker does not have control over what information is obtained, or the amount or kind of loss is limited. The information disclosure does not cause a direct, serious loss to the Vulnerable System.
- None (MVC:N) — There is no loss of confidentiality within the Vulnerable System.
Modified Integrity (Vulnerable System) (MVI)
Modified version of the Base metric "Integrity (Vulnerable System)". It lets you override the Base value for your own environment. This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of a system is impacted when an attacker causes unauthorized modification of system data.
- Not Defined (MVI:X) — Not Defined: the corresponding Base metric value is used (this is the default).
- High (MVI:H) — There is a total loss of integrity, or a complete loss of protection. For example, the attacker is able to modify any/all files protected by the Vulnerable System. Alternatively, only some files can be modified, but malicious modification would present a direct, serious consequence to the Vulnerable System.
- Low (MVI:L) — Modification of data is possible, but the attacker does not have control over the consequence of a modification, or the amount of modification is limited. The data modification does not have a direct, serious impact to the Vulnerable System.
- None (MVI:N) — There is no loss of integrity within the Vulnerable System.
Modified Availability (Vulnerable System) (MVA)
Modified version of the Base metric "Availability (Vulnerable System)". It lets you override the Base value for your own environment. This metric measures the impact to the availability of the impacted system resulting from a successfully exploited vulnerability. It refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email).
- Not Defined (MVA:X) — Not Defined: the corresponding Base metric value is used (this is the default).
- High (MVA:H) — There is a total loss of availability, resulting in the attacker being able to fully deny access to resources in the Vulnerable System; this loss is either sustained (while the attacker continues to deliver the attack) or persistent (the condition persists even after the attack has completed).
- Low (MVA:L) — Performance is reduced or there are interruptions in resource availability. Even if repeated exploitation of the vulnerability is possible, the attacker does not have the ability to completely deny service to legitimate users. The resources in the Vulnerable System 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 Vulnerable System.
- None (MVA:N) — There is no impact to availability within the Vulnerable System.
Modified Confidentiality (Subsequent System) (MSC)
Modified version of the Base metric "Confidentiality (Subsequent System)". It lets you override the Base value for your own environment. Confidentiality impact to systems other than the vulnerable system. If a vulnerability does not impact anything outside the vulnerable system, leave the subsequent system impact metrics as None (N).
- Not Defined (MSC:X) — Not Defined: the corresponding Base metric value is used (this is the default).
- High (MSC:H) — There is a total loss of confidentiality, resulting in all resources within the Subsequent System 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.
- Low (MSC:L) — There is some loss of confidentiality. Access to some restricted information is obtained, but the attacker does not have control over what information is obtained, or the amount or kind of loss is limited. The information disclosure does not cause a direct, serious loss to the Subsequent System.
- Negligible (MSC:N) — There is no loss of confidentiality within the Subsequent System or all confidentiality impact is constrained to the Vulnerable System.
Modified Integrity (Subsequent System) (MSI)
Modified version of the Base metric "Integrity (Subsequent System)". It lets you override the Base value for your own environment. Integrity impact to systems other than the vulnerable system. If a vulnerability does not impact anything outside the vulnerable system, leave the subsequent system impact metrics as None (N).
- Not Defined (MSI:X) — Not Defined: the corresponding Base metric value is used (this is the default).
- Safety (MSI:S) — Safety: exploitation has the potential to injure a human actor or participant (IEC 61508 categories Marginal or worse). Only available for Subsequent System Integrity and Availability.
- High (MSI:H) — There is a total loss of integrity, or a complete loss of protection. For example, the attacker is able to modify any/all files protected by the Subsequent System. Alternatively, only some files can be modified, but malicious modification would present a direct, serious consequence to the Subsequent System.
- Low (MSI:L) — Modification of data is possible, but the attacker does not have control over the consequence of a modification, or the amount of modification is limited. The data modification does not have a direct, serious impact to the Subsequent System.
- Negligible (MSI:N) — There is no loss of integrity within the Subsequent System or all integrity impact is constrained to the Vulnerable System.
Modified Availability (Subsequent System) (MSA)
Modified version of the Base metric "Availability (Subsequent System)". It lets you override the Base value for your own environment. Availability impact to systems other than the vulnerable system. If a vulnerability does not impact anything outside the vulnerable system, leave the subsequent system impact metrics as None (N).
- Not Defined (MSA:X) — Not Defined: the corresponding Base metric value is used (this is the default).
- Safety (MSA:S) — Safety: exploitation has the potential to injure a human actor or participant (IEC 61508 categories Marginal or worse). Only available for Subsequent System Integrity and Availability.
- High (MSA:H) — There is a total loss of availability, resulting in the attacker being able to fully deny access to resources in the Subsequent System; this loss is either sustained (while the attacker continues to deliver the attack) or persistent (the condition persists even after the attack has completed).
- Low (MSA:L) — Performance is reduced or there are interruptions in resource availability. Even if repeated exploitation of the vulnerability is possible, the attacker does not have the ability to completely deny service to legitimate users. The resources in the Subsequent System 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 Subsequent System.
- Negligible (MSA:N) — There is no impact to availability within the Subsequent System or all availability impact is constrained to the Vulnerable System.
Supplemental metrics · 6 metrics
Extra context supplied by the provider. These metrics never change the score.
Safety (S)
Safety is a Supplemental metric: it indicates the degree of impact to the safety of a human actor or participant that can be predictably injured as a result of the vulnerability being exploited. Providing a value is optional and it does not change the score.
- Not Defined (S:X) — The metric has not been evaluated.
- Negligible (S:N) — Consequences of the vulnerability meet definition of IEC 61508 consequence category "negligible."
- Present (S:P) — Consequences of the vulnerability meet definition of IEC 61508 consequence categories of "marginal," "critical," or "catastrophic."
Automatable (AU)
Automatable captures the answer to the question: can an attacker automate exploitation events for this vulnerability across multiple targets, based on steps 1-4 of the kill chain (reconnaissance, weaponization, delivery, exploitation)? It does not change the score.
- Not Defined (AU:X) — The metric has not been evaluated.
- No (AU:N) — Attackers cannot reliably automate all 4 steps of the kill chain for this vulnerability for some reason. These steps are reconnaissance, weaponization, delivery, and exploitation.
- Yes (AU:Y) — Attackers can reliably automate all 4 steps of the kill chain. These steps are reconnaissance, weaponization, delivery, and exploitation (e.g., the vulnerability is “wormable”).
Recovery (R)
Recovery describes the resilience of a system to recover services, in terms of performance and availability, after an attack has been performed. .
- Not Defined (R:X) — The metric has not been evaluated.
- Automatic (R:A) — The system recovers services automatically after an attack has been performed.
- User (R:U) — The system requires manual intervention by the user to recover services, after an attack has been performed.
- Irrecoverable (R:I) — The system services are irrecoverable by the user, after an attack has been performed.
Value Density (V)
Value Density describes the resources that the attacker will gain control over with a single exploitation event. It has two possible values, diffuse and concentrated: .
- Not Defined (V:X) — The metric has not been evaluated.
- Diffuse (V:D) — The vulnerable system has limited resources. That is, the resources that the attacker will gain control over with a single exploitation event are relatively small. An example of Diffuse (think: limited) Value Density would be an attack on a single email client vulnerability.
- Concentrated (V:C) — The vulnerable system is rich in resources. Heuristically, such systems are often the direct responsibility of “system operators” rather than users. An example of Concentrated (think: broad) Value Density would be an attack on a central email server.
Vulnerability Response Effort (RE)
The intention of the Vulnerability Response Effort metric is to provide supplemental information on how difficult it is for consumers to provide an initial response to the impact of vulnerabilities for deployed products and services in their infrastructure.
- Not Defined (RE:X) — The metric has not been evaluated.
- Low (RE:L) — The effort required to respond to a vulnerability is low/trivial. Examples include: communication on better documentation, configuration workarounds, or guidance from the vendor that does not require an immediate update, upgrade, or replacement by the consuming entity, such as firewall filter configuration.
- Moderate (RE:M) — The actions required to respond to a vulnerability require some effort on behalf of the consumer and could cause minimal service impact to implement. Examples include: simple remote update, disabling of a subsystem, or a low-touch software upgrade such as a driver update.
- High (RE:H) — The actions required to respond to a vulnerability are significant and/or difficult, and may possibly lead to an extended, scheduled service impact. This would need to be considered for scheduling purposes including honoring any embargo on deployment of the selected response. Alternatively, response to the vulnerability in the field is not possible remotely. The only resolution to the vulnerability involves physical replacement (e.g.
Provider Urgency (U)
Provider Urgency lets a provider communicate a supplemental severity rating using a standardized colour scheme. It does not change the score.
- Not Defined (U:X) — The metric has not been evaluated.
- Clear (U:Clear) — Provider has assessed the impact of this vulnerability as having no urgency (Informational).
- Green (U:Green) — Provider has assessed the impact of this vulnerability as having a reduced urgency.
- Amber (U:Amber) — Provider has assessed the impact of this vulnerability as having a moderate urgency.
- Red (U:Red) — Provider has assessed the impact of this vulnerability as having the highest urgency.
CVSS 4.0 severity ratings
The qualitative severity rating scale in the CVSS 4.0 specification (use is optional):
| Rating | CVSS score |
|---|---|
| None | 0.0 |
| Low | 0.1 – 3.9 |
| Medium | 4.0 – 6.9 |
| High | 7.0 – 8.9 |
| Critical | 9.0 – 10.0 |
Worked CVSS 4.0 examples
Use “Load a worked example” in the calculator to open any of these. Scores are computed live by the same engine.
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:NNetwork, no privileges, no user interaction, full impact on the vulnerable system only.
Source: FIRST CVSS v4.0 Examples page.
Open in the calculatorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:HThe maximum CVSS 4.0 vector: High impact on the vulnerable and the subsequent system.
Source: FIRST CVSS v4.0 Examples page.
Open in the calculatorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:NA user must act (Active), and the impact lands on a subsequent system (the browser).
Source: FIRST CVSS v4.0 Examples page.
Open in the calculatorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:UExploit Maturity Unreported lowers the score; the same vector without E:U scores 7.7 (CVSS-B).
Source: FIRST CVSS v4.0 Examples page.
Open in the calculatorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:L/VA:L/SC:N/SI:N/SA:N/CR:H/IR:L/AR:L/MAV:N/MAC:H/MVC:H/MVI:L/MVA:LSecurity Requirements and Modified Base metrics re-score the same finding for one environment (CVSS-B 8.3).
Source: FIRST CVSS v4.0 Examples page.
Open in the calculatorThe four CVSS versions
Read the start of the vector to know which version it is, and score it in that version.
| Version | Vector starts with | Metric groups | How the score is produced | Severity labels |
|---|---|---|---|---|
| CVSS v4.0 | CVSS:4.0/ | Base, Threat, Environmental, Supplemental | MacroVector lookup in FIRST's table, then interpolation | FIRST scale (None to Critical) |
| CVSS v3.1 | CVSS:3.1/ | Base, Temporal, Environmental | Closed equations; Roundup with integer method (Appendix A) | FIRST scale (None to Critical) |
| CVSS v3.0 | CVSS:3.0/ | Base, Temporal, Environmental | Closed equations; Modified Impact exponent 15; plain "Round up" | FIRST scale (None to Critical) |
| CVSS v2.0 | no prefix, e.g. AV:N/AC:L/… | Base, Temporal, Environmental | Closed equations; round_to_1_decimal | None defined by FIRST; NVD uses Low, Medium, High |
CVSS v3.1 vs v4.0
| Aspect | CVSS v3.1 | CVSS v4.0 |
|---|---|---|
| Scoring method | Closed-form equations | MacroVector lookup plus interpolation; no single formula |
| Exploitability metrics | AV, AC, PR, UI | AV, AC, AT (Attack Requirements, new), PR, UI |
| User Interaction values | None, Required | None, Passive, Active |
| Impact metrics | C, I, A, with a Scope metric for impact beyond the component | VC, VI, VA on the Vulnerable System and SC, SI, SA on Subsequent Systems; Scope is gone |
| Time-based group | Temporal: Exploit Code Maturity, Remediation Level, Report Confidence | Threat: Exploit Maturity only |
| Supplemental metrics | None | Safety, Automatable, Recovery, Value Density, Vulnerability Response Effort, Provider Urgency; no effect on the score |
| Defaults for Not Defined | Temporal and Environmental metrics are skipped | Always applied: Exploit Maturity counts as Attacked, Security Requirements count as High |
| Score label | Base, Temporal or Environmental score | CVSS-B, CVSS-BT, CVSS-BE or CVSS-BTE |
| Vector order | Preferred order; any order must be accepted | The specification's order is mandatory |
CVSS v3.0 vs v3.1
The metrics and Base equations are the same. The v3.1 specification changes the Modified Impact formula used for the Environmental score when Modified Scope is Changed (exponent 13 with MISS × 0.9731, where v3.0 used exponent 15) and adds Appendix A, an integer method for Roundup. This site scores each prefix with its own version's equations.
Frequently asked questions
What is the CVSS 4.0 calculator and how is the score computed?
CVSS 4.0 is the version of the Common Vulnerability Scoring System that FIRST.org published on 1 November 2023. The calculator takes the Base, Threat and Environmental metric values, maps them to a six-digit MacroVector, looks that MacroVector up in FIRST's score table, and interpolates down within the equivalence set to a score for the exact vector, rounded to one decimal. Supplemental metrics do not change the score.
What do CVSS-B, CVSS-BT, CVSS-BE and CVSS-BTE mean?
They are the nomenclature the v4.0 specification defines for labelling a score by the metric groups used: CVSS-B is Base only, CVSS-BT adds Threat, CVSS-BE adds Environmental, and CVSS-BTE uses all three. The specification says the label should be used wherever a numerical CVSS value is displayed or communicated. NVD and product maintainers typically publish only the Base score, CVSS-B.
What do AT, SC, SI and SA mean in a CVSS 4.0 vector?
AT is Attack Requirements: whether the attack depends on specific deployment and execution conditions of the vulnerable system (None or Present). SC, SI and SA are the Confidentiality, Integrity and Availability impact on the Subsequent System, meaning systems other than the vulnerable one. VC, VI and VA are the same impacts on the Vulnerable System. If nothing outside the vulnerable system is affected, leave SC, SI and SA at None.
Is a CVSS 4.0 score the same as the CVSS 3.1 score?
Not necessarily. The versions use different metrics and different scoring methods. In FIRST's own v4.0 examples, the same unauthenticated remote vulnerability with High impact is 9.8 in v3.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) and 9.3 in v4.0 (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N). Score a vulnerability in the version your process requires rather than converting.
What happens if I leave the Threat and Environmental metrics at Not Defined?
The score is still complete. In v4.0 the Not Defined defaults are always applied: Exploit Maturity counts as Attacked (the worst case) and the Confidentiality, Integrity and Availability Requirements count as High. A Modified Base metric left at Not Defined uses the value of its Base metric.
How is a CVSS 4.0 vector string written?
It starts with CVSS:4.0, followed by metric:value pairs separated by slashes, for example CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. All Base metrics must appear, Threat, Environmental and Supplemental metrics are optional, a metric must not repeat, abbreviations are case sensitive, and the specification says any ordering other than its own table order is invalid.
Sources and official calculators
- CVSS v4.0 Specification Document
- CVSS v4.0 User Guide
- CVSS v4.0 Examples
- FIRST reference calculator (GitHub, BSD-2-Clause)
Official calculators: FIRST CVSS v4.0 calculator · NVD CVSS v4.0 calculator
CVSS is a trademark of FIRST.org, Inc. This calculator is an independent implementation of the published specifications and is not affiliated with FIRST or NIST. Specification text and examples were read on 3 November 2026.