A contextual CVSS scoring system allows opted-in vulnerability disclosure programs to combine the consistency of the industrialized CVSS v.3.0 standard with their respective business context. Since every company has different risk and threat models, the final impact severity of vulnerability can only be determined after thorough examination by the security analysts. While the final severity assessment is made at the discretion of the participating company, the following formula serves as a guideline when suggesting the report’s severity.
CVSS = CVSSv3 base score + business impact modifier (optional)
Intigriti uses the CVSS v3 industry standard as a baseline for severity scoring. Regardless of the numeric scoring, there can always be escalating or mitigating factors given the provided context.
For example, vulnerability submissions resulting in potential revenue losses can be highly contextual, especially in situations where there is no direct financial gain for the attackers (e.g., bypassing a payment wall). Similarly, a vulnerability in highly sensitive or exposed business components may have some indirect consequences, such as reputational damage. Companies may decide to reclassify a vulnerability when contextual mitigating or escalating factors arise. Whenever a business impact modifier is evoked, this will be clearly and transparently communicated towards the researcher. A business impact modifier can only downgrade the severity score as calculated by the CVSSv3 calculator by maximum one category, but can upgrade the score to any category.
Intigriti strives to provide seamless communication and cooperation between companies and security researchers. In the event of any disputes regarding the outcome of a vulnerability report, the Intigriti mediation team will examine the situation from a neutral point of view and provide advice if needed.
Base score using CVSS v3
The severity of a vulnerability is calculated by using the CVSS v3 calculator. Intigriti uses the base metrics to calculate the CVSS v3 score. The critical to exceptional category is reserved for exceptional issues that reflect a CVSS v3 score of 9.5 - 10.0.
The CVSS v3 score is calculated using the following metrics:
Attack Vector (AV)
This metric reflects the context by which vulnerability exploitation is possible. This metric value (and consequently the Base score) will be larger the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable component.
Metric Value | Description |
Network (N) | A vulnerability exploitable with network access means the vulnerable component is bound to the network stack and the attacker's path is through OSI layer 3 (the network layer). Such a vulnerability is often termed "remotely exploitable" and can be thought of as an attack being exploitable one or more network hops away (e.g., across layer 3 boundaries from routers).
An example of a network attack is an attacker causing a denial of service (DoS) by sending a specially crafted TCP packet from across the public Internet (e.g., CVE 2004 0230). |
Adjacent (A) | A vulnerability exploitable with adjacent network access means the vulnerable component is bound to the network stack, however the attack is limited to the same shared physical (e.g., Bluetooth, IEEE 802.11), or logical (e.g., local IP subnet) network, and cannot be performed across an OSI layer 3 boundary (e.g., a router).
An example of an Adjacent attack would be an ARP (IPv4) or neighbor discovery (IPv6) flood leading to a denial of service on the local LAN segment. |
Local (L) | A vulnerability exploitable with Local access means that the vulnerable component is not bound to the network stack, and the attacker's path is via read/write/execute capabilities. In some cases, the attacker may be logged in locally in order to exploit the vulnerability, otherwise, she may rely on User Interaction to execute a malicious file. |
Physical (P) | A vulnerability exploitable with Physical access requires the attacker to physically touch or manipulate the vulnerable component. Physical interaction may be brief or persistent. An example of such an attack is a cold boot attack which allows an attacker to access to disk encryption keys after gaining physical access to the system, or peripheral attacks such as Firewire/USB Direct Memory Access attacks. |
Attack Complexity (AC)
This metric describes the conditions beyond the attacker's control that must exist to exploit the vulnerability. Such conditions may require the collection of more information about the target, the presence of certain system configuration settings, or computational exceptions.
NOTE: These conditions also include the effort required to pull off a successful attack (not finding it). Conditions that make a vulnerability less scalable or convenient to exploit against a larger group of users will have a higher complexity (for example: the need to brute force or obtain a certain value such as a non-numeric ID, timing attacks, only works on specific browsers, …).
Metric Value | Description |
Low (L) | Specialized access conditions or extenuating circumstances do not exist. An attacker can expect repeatable success against the vulnerable component. |
High (H) | A successful attack depends on conditions beyond the attacker's control. That is, a successful attack cannot be accomplished at will, but requires the attacker to invest in some measurable amount of effort in preparation or execution against the vulnerable component before a successful attack can be expected. 2 |
Privileges Required (PR)
This metric describes the level of privileges an attacker must possess before successfully exploiting the vulnerability. This metric is greatest if no privileges are required.
NOTE: Accounts obtained through public registration without prior approval are considered non-privileged. This does not apply for leaked or provided credentials.
Metric Value | Description |
None (N) | The attacker is unauthorized prior to attack, and therefore does not require any access to settings or files to carry out an attack. |
Low (L) | The attacker is authorized with (i.e. requires) privileges that provide basic user capabilities that could normally affect only settings and files owned by a user. Alternatively, an attacker with Low privileges may have the ability to cause an impact only to non-sensitive resources. |
High (H) | The attacker is authorized with (i.e. requires) privileges that provide significant (e.g. administrative) control over the vulnerable component that could affect component-wide settings and files. |
User Interaction (UI)
This metric captures the requirement for a user, other than the attacker, to participate in the successful compromise of the vulnerable component. This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner. This metric value is greatest when no user interaction is required.
NOTE: We consider every action a separate user must take as user interaction, even if it is just visiting a link or performing an action within the application. An exception can be made for situations in which the attack is automatically triggered within a common user flow (for example: "wormable" stored XSS on the front page) or in a feed or component that is part of the core business case (for example: CSRF by opening an e-mail in an e-mail client). Exceptions are made at the discretion of the program owner.
Metric Value | Description |
None (N) | The vulnerable system can be exploited without interaction from any user. |
Required (R) | Successful exploitation of this vulnerability requires a user to take some action before the vulnerability can be exploited. For example, a successful exploit may only be possible during the installation of an application by a system administrator. |
Scope (S)
When the vulnerability of a software component governed by one authorization scope can affect resources governed by another authorization scope, a scope change has occurred.
NOTE: We consider the scope as changed if the new scope is also indirectly covered by the bug bounty program (for example: if you can leverage a vulnerability in the application layer to gain control over the network layer). We only consider scope changes that result in a higher authorization level for the attacker (e.g., from the web application to the local file system or network, but not from the web application to the browser).
Metric Value | Description |
Unchanged (U) | An exploited vulnerability can only affect resources managed by the same authority. In this case the vulnerable component and the impacted component are the same. |
Changed (C) | An exploited vulnerability can affect resources beyond the authorization privileges intended by the vulnerable component. In this case the vulnerable component and the impacted component are different. |
Confidentiality Impact (C)
This metric measures the impact to the confidentiality of the information resources managed by a software component due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Metric Value | Description |
High (H) | There is total loss of confidentiality, resulting in all resources within the impacted component being divulged to the attacker. Alternatively, access to only some restricted information is obtained, but the disclosed information presents a direct, serious impact. For example, an attacker steals the administrator's password, or private encryption keys of a web server. |
Low (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 constrained. The information disclosure does not cause a direct, serious loss to the impacted component. |
None (N) | There is no loss of confidentiality within the impacted component. |
Integrity Impact (I)
This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information.
Metric Value | Description |
High (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 impacted component. Alternatively, only some files can be modified, but malicious modification would present a direct, serious consequence to the impacted component. |
Low (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 constrained. The data modification does not have a direct, serious impact on the impacted component. |
None (N) | There is no loss of integrity within the impacted component. |
Availability Impact (A)
This metric measures the impact to the availability of the impacted component resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the impacted component, this metric refers to the loss of availability of the impacted component itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of an impacted component.
Metric Value | Description |
High (H) | There is total loss of availability, resulting in the attacker being able to fully deny access to resources in the impacted component; this loss is either sustained (while the attacker continues to deliver the attack) or persistent (the condition persists even after the attack has completed).
Alternatively, the attacker has the ability to deny some availability, but the loss of availability presents a direct, serious consequence to the impacted component (e.g., the attacker cannot disrupt existing connections, but can prevent new connections; the attacker can repeatedly exploit a vulnerability that, in each instance of a successful attack, leaks a only small amount of memory, but after repeated exploitation causes a service to become completely unavailable). |
Low (L) | There is reduced performance or interruptions in resource availability. Even if repeated exploitation of the vulnerability is possible, the attacker does not have the ability to completely deny service to legitimate users. The resources in the impacted component are either partially available all the time, or fully available only some of the time, but overall, there is no direct, serious consequence to the impacted component. |
None (N) | There is no impact to availability within the impacted component. |
Vulnerability ratings
Severity rating | CVSS v3 score |
None | 0.0 |
Low | 0.1 - 3.9 |
Medium | 4.0 - 6.9 |
High | 7.0 - 8.9 |
Critical | 9.0 - 9.4 |
Exceptional | 9.5 - 10.0 |
Exceptions
Some vulnerabilities only may only slightly impact individual CVSS v3 metrics outlined above, in a way that they do not warrant a severity upgrade. We have outlined these edge cases below, so you know what severity assessment to expect:
Bug type | Base severity |
Reflected HTML injection | Low |
HTML injection in e-mails | Low |
Disclosed PHP info/debug page | Low |
E-mail verification bypass | Low |
Open redirect without additional impact | Low |
Broken link hijacking (high trafflic links) | Low |
Vulnerability chains
A recurrent question when reporting vulnerabilities (or bugs) is whether to group them into a single report or send multiple reports.
Each vulnerability should have its own report, except in the following situations
If the same bug, with the same root cause, affects multiple URLs or assets, send a single report mentioning all vulnerable endpoints. This includes structural issues (asset-wide vulnerabilities such as a CSRF affecting most endpoints of a site).
If you are reporting a bug chain, include everything in the same submission. The impact of the total chain will be taken into account for calculating the bounty.
Duplicate policy
In the bug bounty industry, duplicate reports are reports where described behavior, its exact location and cause within the codebase and the security consequences linked to it are already known to the customer/bug bounty vendor in an "open" or "accepted risk" submission. The duplicate report does not raise the priority, severity, or change resolution steps from the initial assessment.
Intigriti highly recommends to request the involved researcher to verify the patch before closing a submission. A bonus can be used to incentivize the researcher to test the fix.
Examples
A bypass is found for a previously reported, but fixed issue.
We do not consider this a duplicate. Once the report is closed, it is considered fixed. If a security researcher manages to get around the patch, they will receive a bounty according to its severity.
CSRF protection is missing throughout the whole website, multiple CSRF reports come in.
We consider this a duplicate: this is a structural issue, most to all endpoints are affected, and no extra bounties can be claimed for additional reports. The customer is aware that CSRF protection is missing in general, additional reports provide no extra value and the issue can be fixed with one change (the implementation of CSRF validation in the request controller). The prevalence of the issue may be considered when determining the severity of the initial report.
XSS vulnerabilities have been found on some but not all endpoints throughout the app
We do not consider these reports a duplicate if there is no common root cause: every finding is unique and requires a separate fix. The fix for the initial XSS would not have fixed the other XSS vulnerabilities. The customer can request a timeout to conduct a full assessment by suspending the program temporarily or putting XSS out of scope for the time being.
Excluding chain: A SSRF vulnerability is discovered that utilizes an internally known open redirect
We do not consider the SSRF report a duplicate, even though it leverages a known or out of scope behavior. The SSRF vulnerability itself is useless without the open redirect, but the SSRF leverages its impact, and the initial report gets reprioritized. A bounty is paid out according to the severity of the SSRF. No separate bounty is awarded for the open redirect.
An open redirection has been reported. An XSS vulnerability using the JavaScript: protocol was reported earlier at the same location.
We consider this report a duplicate, as the severity of an open redirection issue is lower than the severity of XSS. The severity of the initial report is not changed nor reprioritized.
An XSS vulnerability using the JavaScript: protocol has been reported. An open redirection issue was reported earlier at the same location.
We do consider this report as a duplicate, but highly recommend to reward a bonus for the raised severity. Since the severity of the XSS is higher than the initial report (open redirection). The difference between the new severity and the old severity gets paid. If a low (€100) issue gets upgraded to a medium (€500), €400 will be paid as a bonus.
Regression: an IDOR was reported. The exact same issue was reported, fixed and closed earlier. Due to a regression, the vulnerability reappears.
We do not consider this report a duplicate, as the initial ticket was closed and would not have been fixed without the new report.
Footnote
Severities within our platform only reflect the severity regarding the security impact of a certain behavior and may not directly reflect the internal prioritization. As new threats emerge, we will continue to update this standard.
Intigriti’s vulnerability analysis and mediation team will take the guidelines above into consideration when providing advice. The final decision to accept or reject a report, or to set the severity lies with the program owner.