Note: these standards will go into effect on January 6th, 2025 and replace the contextual CVSS guidelines.
The Intigriti Triage Standards are established to provide a comprehensive and consistent framework for evaluating the severity of vulnerabilities reported by security researchers. This policy aims to ensure that vulnerabilities are assessed fairly, transparently, and in alignment with both industry standards and the specific context of each bug bounty program. We acknowledge that no severity scoring system is perfect, but a well-defined policy helps manage expectations and ensure consistent evaluations. The triage team will always assess findings based on their impact in accordance with the program’s severity scoring guidelines. It is important to note that severities on the platform do not equate to the importance or risk to a company but are assessed within the context of the bug bounty scheme.
1. Assessment methods
1.1. Assessment based on proof-of-concept
During an assessment on proof-of-concept, the submissions’ severity will be calculated based on a successfully executed attack scenario as reproduced from the instructions described in the report. For example, a cross-site-scripting attack (XSS) that could result in remote code execution (RCE) on a privileged machine will be scored with the greatest potential impact in mind.
1.2. Assessment based on vulnerability type
During an assessment on vulnerability type, the submissions’ impact score is calculated based on their initial and immediate effect on the vulnerable system. Additional exploitation steps or probabilities are not considered within an assessment based on vulnerability type. For example, a cross-site-scripting attack (XSS) may be further leveraged to initiate an account takeover by changing the e-mail address of the logged-in user. The escalation path from arbitrary JavaScript execution to a full account takeover might already be tracked as an internal steps and may be mitigated by situational parameters such as the presence of multi-factor authentication for privileged accounts. In an assessment on vulnerability type, this scenario will be scored as a cross-site-scripting vulnerability regardless of the proof of concept.
By default, Intigriti’s triage team will assess a report’s severity based on the provided proof of concept, unless otherwise stated in the program guidelines. At any point, program owners can decide to score vulnerabilities based on their vulnerability type instead and choose not to include escalating or mitigating factors illustrated in a proof of concept in the final severity scoring. The decision to assess a vulnerability based on vulnerability type remains at the discretion of the program owners and is ineligible for mediation.
For attacks to qualify as a vulnerability, there needs to be a tangible gain for a potential attacker exploiting the behavior. For example, the ability to view another users’ notification preferences or to add something to their shopping cart may not meet the bar to be assessed as a vulnerability, unless a programs’ preferences state otherwise.
1.3. Custom assessments
Program owners can opt to follow their own severity scoring standards or introduce amendments to the existing standards, which can be published through the program guidelines. Any instructions or guidelines in the programs’ description or scope will always prevail over the platform standards outlined in this document.
2. Submission handling standards
2.1 Vulnerability Chains
Submissions may include multiple findings or vulnerabilities to conjointly demonstrate a greater impact. However, it should be noted that at no point finders should hoard or stockpile vulnerabilities for longer than 48 hours.
When vulnerabilities are part of a chain, meaning one vulnerability enables or escalates another, the combined impact will be considered if the vulnerabilities are considered unique and not previously reported. Each vulnerability within the chain that is independently fixable may be tracked as a different issue and subsequent findings referencing the same behaviour may partially be considered a duplicate if the newer finding does not show additional impact. If the new finding does show additional impact, the difference between the impacts of the two submissions should be considered for the new finding.
Examples:
Escalating findings in single report: an open redirection vulnerability and a server side request forgery (SSRF) vulnerability are reported resulting in remote code execution. The final impact will be assessed (remote code execution).
Non-escalating findings in a single report: multiple findings are reported in a single report that are unrelated from another and are not considered duplicates. The findings should be treated and scored individually, preferably by asking the finder to create a report per findings.
Escalating findings across multiple reports: an open redirect is reported by researcher A and sequentially an SSRF vulnerability resulting in remote code execution, referencing the open redirect is reported by researcher B. Researcher B shows additional impact, so the difference between the two reports will be considered (remote code execution - open redirect).
Escalating findings across duplicate reports: researcher A reports an open redirection vulnerability and a server side request vulnerability (SSRF) resulting in remote code execution. Later, researcher B reports the same chain resulting in remote code execution, but with a different open redirect or SSRF vulnerability. The highest impact (RCE) are considered as a duplicate and the report is tracked as separate open redirect or SSRF vulnerability.
2.2 Reporting privacy, compliance and governance issues
Security and privacy go hand in hand and are often equally important to an organization. Bug bounty and vulnerability disclosure platforms offer tools to capture and assess vulnerabilities for which universal scoring standards exist, whereas privacy concerns are often related to local compliance laws and regulations. As such, triage teams and program managers are often not able to assess privacy concerns directly through their vulnerability disclosure policy, unless otherwise stated.
2.2.1. Privacy issues without a security impact
Functional bugs or process flaws resulting in compliance, privacy and governance issues that do not pose an immediate and exploitable threat to users are typically ineligible to be scored as a vulnerability. By default, they will be closed as “informative” by the triage team.
Example: a cookie that is not correctly scoped or set without the proof that it can be stolen.
Example: a resource that is not immediately deleted from the server or cache after its deletion was requested, without the ability for an attacker to easily retrieve it.
2.2.2. Privacy issues with security impact
Vulnerabilities that directly pose significant privacy risk to their users should be evaluated for their total impact outside of the scope of the vulnerable system. For example, a confidentiality breach on a vulnerable component may result in an integrity breach outside of the vulnerable component due to the nature of the obtained data. While the extent of indirect post-exploitation impact may be speculative, the triage team will assess the maximum impact scenario. The final decision is at the company's discretion.
Example: an Insecure Direct Object Reference (IDOR) vulnerability is discovered that leaks a significant amount of personal information or system critical data. On a case-by-case basis, the indirect integrity impact on the vulnerable users may be considered as part of the severity analysis, resulting in a critical severity when the proof-of-concept assessment method is applied.
2.3 Reporting findings of speculative nature
Some vulnerabilities may not have direct business impact but may introduce risks to be exploited in certain situations. For all speculative scenarios, the final determination is at the discretion of the program owners.
2.3.1. Test Environments
Vulnerabilities discovered in test environments should be assessed based on their potential impact in production environments. If a vulnerability discovered would have been deployed to the production environment at a later moment without the existence of the vulnerability report, it should be considered as caught early and the full impact should be considered as if it were on the production environment. If a vulnerability exists only in a test environment and there is no impact on the production environment, it will be forwarded as Undecided and its acceptance is at the discretion of the company.
2.3.2. Unused Vulnerable Code
Vulnerabilities discovered in unused code will be forwarded with severity ‘none’ by default, unless there is tangible evidence evidence that the vulnerable code is either used on a backend system, by an authorized third-party or that will be integrated in a future version of the application.
Example: the presence of a vulnerable or outdated Angular version will not be eligible for vulnerability scoring as long as no workable proof-of-concept can be provided.
Example: a program owner that has their own popular open source libraries may not use certain classes or default configurations of their own code, but their authenticated third parties may do so. If a vulnerability is discovered in code written by the program owners that is not deprecated but currently not in use, it will be scored as a vulnerability.
Example: a JavaScript file of an admin panel shows the presence of a cross-site-scripting vulnerability, but since the tester does not have an administrative account, they are unable to demonstrate the execution of a proof of concept. The report will be forwarded as Undecided and its eligibiliy decision will be delayed. If the code is not implemented yet, complexity may be set to High during the severity assessment.
2.3.3. Entropy thresholds
Given enough resources and time, it may be possible to predict certain secrets such as passwords, one-time-passwords (OTP), verification codes or confirmation codes. While a low secret entropy or user input complexity requirements do typically not constitute to a reportable finding on their own, they may be eligible for to be triaged in certain conditions.
If the secret or identifier is (partially) predictable or prone to enumeration attacks
E.g. A six-digit authorization code valid for one hour does not expire after an invalid attempt
E.g. a Base62 Salesforce Identifier that follows a predictable scheme
If the secret is unpredictable, but the identified behavior bypasses existing authorization mechanisms
E.g. An Insecure Direct Object Reference (IDOR) vulnerability using system generated ID’s, such as an UUID, should be considered as a valid finding with a high complexity.
3. Metric clarifications
3.1. CVSSv3
3.1.1. 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. |
3.1.2. 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. 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, …). The effort required to discover a vulnerability, such as the requirement to bypass SSL pinning, is not considered for the attack complexity metric.
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 |
3.1.3. 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. |
3.1.4. 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. |
3.1.5. 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. |
3.1.6. 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.
NOTE: In multi-tenant environments with shared resources, confidentiality impact is typically considered low if only partial access controls are bypassed, limiting data exposure to the attacker's initial access environment, unless the restricted information obtained impacts all resources for the affected tenant (such as complete access to the database or file system or super admin creation by a low privileged user), or if the disclosed information poses a significant risk to the core business.
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. |
3.1.7. Integrity Impact (I)
This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information.
Note: In multi-tenant environments with shared resources, integrity impact is typically considered low if only partial access controls are bypassed, limiting data modification to the attacker's initial access environment, unless the restricted information altered impacts all resources for the affected tenant (such as complete access to the database or file system), or if the altered information poses a significant risk to the core business.
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. |
3.1.8. 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.
NOTE: The ability to delete or overwrite data does not affect the availability of a system, but rather the integrity of a system.
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. |
4. Scoping Standards
4.1 Scope Boundaries
An important part of participating in engagements through the Intigriti platform is to understand and respect the testing scope. Active testing on unauthorized testing scope exposes the tester to legal risks and unexpected damages. We recommend program owners against rewarding findings on out-of-scope assets if they cannot be formally put in-scope, to drive fairness with other participants that respect the scope and prevent incentivizing out-of-scope testing. In the following section, we describe how we handle the scope assessment of different scenarios.
By default, submissions that describe a behavior on a certain scope that has impact on a different scope will be treated as submissions on the scope the reported behavior is impacting. For these submissions, the company can re-assign the scope to a category they see more fitting.
4.1.1. Explicitly out of scope
Vulnerabilities discovered in components or functionalities that are explicitly listed as out of scope in the bug bounty program's documentation are not considered for assessment or reward and may result in a warning or sanction for unauthorized testing.
4.1.2. Not Explicitly In- or Out of Scope
We generally discourage rewarding findings that are not explicitly in- or out of scope in the platform guidelines. The way the triage team handles these findings by default depends on how they were discovered and what impact they have in relation to the scope. The mediation team is unable to mediate over disputes that arise from reports on assets that are not explicitly in-scope in the program guidelines at the time of their submission.
Findings obtained through active testing
Active findings are vulnerabilities obtained through active vulnerability testing, which is only allowed on authorised targets. Valid findings will be forwarded as “Out of scope” and are not eligible for a reward. They may result in a warning or sanction for unauthorised testing.
Findings obtained through passive exploration
Passive findings are actionable vulnerabilities in company assets obtained through inspection and normal application usage that do not involve altering or manipulating in such a way that could be seen as hacking, fraud or manipulation or resource exhaustion, denial of service or intrusive scaning. Examples include dangling DNS records that may result in domain takeovers, directory listing, the exposure of secrets within the normal flow of a web application or business logic vulnerabilities that can be triggered by using the normal web interface. Passive findings on assets that are not explicitly out-of-scope will always be forwarded to the company, how they are assessed depends on the scope they influence.
Recommended approach
Obtained through / impacted scope | In-scope impact | No in-scope impact |
Active testing | No bounty suggested (no severity) | Closed as out of scope |
Passive exploration | Delayed decision (undecided) | No bounty suggested (no severity) |
4.1.3. Explicitly in-scope
Vulnerabilities affecting components or functionalities that are explicitly listed as in scope at the time of their submission will be assessed based on their impact within the defined boundaries. The triage team will ensure that only vulnerabilities within the scope are evaluated for severity and potential reward.
4.2 Vulnerabilities in Third-Party Components
Vulnerabilities found in third-party components will be assessed based on their impact on the overall system. The severity will consider whether the third-party component is critical to the system and if the vulnerability could be exploited in a meaningful way. If a vulnerability is found by a researcher in a third-party component, the finder should always inform the owner or vendor of the vulnerable component prior to reporting it to their users.
4.2.1.Reports regarding cloud-based third-party services
4.2.1.1. Vulnerabilities in cloud-based third-party services
Vulnerabilities identified in cloud-hosted third parties, such as SaaS or PaaS solutions, should be directly reported to the party that is responsible for implementing the fix, and will be treated as out of scope unless the third-party is explicitly mentioned in the scope. Cloud-hosted third-party domains that are part of a wildcard scope are also considered out-of-scope for active testing. While reporting issues in third-party cloud domains accidentally included in the scope, for example through a wildcard, will not result in a warning, they may not be eligible for a bounty.
Example: an Insecure Direct Object Reference (IDOR) vulnerability is discovered in the chat plugin embedded on a target’s website, allowing an attacker to read all conversations. If the vulnerable API endpoints belong to the third party, the issue should be directly reported to them.
4.2.1.2. Misconfigurations in cloud-based third-party services
Misconfigurations or set-ups that are deemed insecure as per the vendor’s documentation will always be forwarded to program owners and treated as a normal submission as long as their impact can be considered in-scope, unless otherwise stated.
Example: Due to an insecure CORS configuration set by the program owners, it is possible for an attacker to retrieve a victim’s chat messages in a third party application. This is not leveraging a vulnerability in the chat system itself, but rather an oversight or in the implementation.
Example: a third-party service allows their users to create queries or run commands in their own query or expression language processing unsafe user input, resulting in a vulnerability. If the vulnerability could have been avoided by the implementers by following the documentation and best practices, the report will be forwarded as a normal submission.
4.2.2. Vulnerabilities in on-premises third-party services
Vulnerabilities in on-premises third-party plugins, libraries, dependencies or software will always be forwarded to program owners, unless otherwise stated. Bounty eligibility and severity assessment will depend on the delivered actionable value and vendor awareness.
Recommended approach
| No workable patch available | Workable patch available |
Vendor not aware | No bounty suggested (domain set to other) | No bounty suggested (domain set to other) |
Vendor aware | Delayed bounty decision (undecided) | Full severity assessment, bounty eligibility at company’s discretion for first 14 days |
We encourage all reporters to report vulnerabilities directly to their respective component owners prior to informing affected users or customers. Customers and platforms reserve the right to initiate coordinated vulnerability disclosure with third-party component owners. We understand that sometimes, finders are not aware that they have identified a vulnerability in a third-party vendor and will provide the reporters with the opportunity to directly report the issue to the vendor to meet awareness standards.
4.2.3. Leaked credentials in third-party services
4.2.3.1. Credential types
We differentiate between two types of credentials:
System credentials
Credentials that are not directly tied to a specific individual, such as admin, webmaster, root, api, ...
Upon discovery, system credentials may be validated by authenticating and deauthenticating immediately to avoid unnecessary pivoting.
Personal credentials
Credentials that belong to a certain user or individual with the company of the program owners, such as alice.doe or james.doe. They should never be validated and should be reported immediately to respect the privacy of the individual. If, after validation by the company, the credentials turn out to be invalid or not correct, the submission will be closed in such a way that it does not negatively impact the reporters’ statistics.
B2B / B2C User credentials
Credentials that belong to customers or other non-employees of the target company. They should never be validated and should be reported immediately to respect the privacy of the individual.
4.2.3.2. Leak origins
Internal first-party leak
Leaks that are the result of a security misconfiguration or oversight, such as the accidental publication of hardcoded credentials in publicly available source code.
Public third-party leak
Credentials leaked as part of a data breach in a public forum or asset. While these reports informing program owners about publicly leaked credentials may be valuable, bounties are typically not recommended to prevent abuse.
Private third-party leak
Hackers should at no point purchase vulnerability data, tokens or access to leaked credentials to avoid funding illicit marketplaces and illegal activities. Offending reporters may be sanctioned as part of our community code of conduct.
Recommended approach
| Internal first-party leak | Public third-party leak | Private third-party leak |
System credentials | Full severity assessment | Delayed bounty decision (undecided) | Code of conduct violation, forwarded as out of scope |
Personal / employee credentials | Delayed bounty decision (undecided) | No bounty suggested (domain set to other) | Code of conduct violation, forwarded as out of scope |
Non-privileged user / B2B / B2C user credentials | Delayed bounty decision (undecided) | Reject as out of scope
| Code of conduct violation, forwarded as out of scope
|
5. Duplication Standards
Bug bounty programs are designed to reward individual reports for impact and added value. If an issue is already known, or would be remidiated as part of another report, it is typically not eligible for a monetary reward. When vulnerabilities are similar or alike, discussion may arise as to what constitutes a duplicate finding. We have listed some common scenario’s:
5.1 Same Vulnerability, Different Impact
If a report describes a finding that has been reported by another researcher, it will only be considered for assessment by the program owners if the new reports highlights additional impact. In the event that the new impact is deemed valid, the final impact assessment will exclude any rewards already awarded for the initial impact.
5.2 Same Vulnerability, Different Hosts
Vulnerabilities reported on different hosts or instances should be assessed individually if there are reasonable grounds to believe that the assessment of the initial finding would not have led to the discovery of the other affected hosts.
5.3 Same Vulnerability Class on All Affected Components or Endpoints
When a vulnerability class affects multiple components or endpoints, it should be reported as a single issue if the root cause is identical and the issue can be fixed with a unified solution. For instance, if a cross-site scripting (XSS) vulnerability is found across multiple endpoints but has the same underlying cause, it should be considered a single finding. The complete or structural lack of protection against a certain vulnerability on all endpoints of a named component can be considered as a single root cause, even if it requires multiple assets or components to be updated. The highest impact across all affected components will be evaluated to determine the severity.
For structural issues that are present on multiple endpoints, Intigriti’s recommendation is to accept and reward the first two valid reports.
5.4 Regressions and Bypasses
Vulnerabilities that reappear after being previously fixed or that bypass existing protections should be reported and assessed based on their impact. If a previously fixed issue reoccurs due to regression or if a new method of bypassing a fix is discovered, it should be treated as a new vulnerability and evaluated accordingly. The triage team will consider the additional risk posed by regressions and bypasses.
5.5 Internally Known Vulnerabilities
Organisations may have multiple ways to detect and identify security anomalies or vulnerabilities. It may occur that a vulnerability reported by a finder is already known to a company without it being referenced on the platform, which is why reports may be closed as a duplicate after initial assessment by triage. Intigriti may request a timestamped internal reference to the vulnerability when it sees an influx of submissions closed as an internal duplicate.
5.6 Unmanaged Asset
When vulnerabilities are discovered on an asset that is not actively managed, for instance a forgotten subdomain within a wildcard scope, and upon discovery of this asset the intention is to decommission it, the program can choose to duplicate subsequent reports for this asset within ten business days of the first report being accepted. The asset should be added to the Out of Scope section of the program as soon as possible to prevent researchers investing their time discovering vulnerabilities in this asset.
6. Rulings and exceptions
We acknowledge that existing severity metrics do not always cover specific scenarios in which the metrics are unclear or not fitting. For transparency reasons, we have listed a non-exhaustive list of vulnerability or attack scenarios and how we have treated them in the past. Note that this list of examples and their respective approaches may change at any moment in the future and does not come with a guarantee that similar decisions will be made in the future.
6.1. Open redirect
Open redirects that do not serve any other purpose than to redirect a user to an external page will be treated as low severity submissions.
6.2. Content, image, HTML and CSS injection
Content, HTML and CSS injection unless critical confidential data can be stolen (such as the case with dangling markup injection) will be treated as low severity submissions.
This also applies for community-curated pages such as Wiki’s.
6.3. Broken link hijacking
Broken link injection or hijacking submissions will be scored as low severity, unless the URL is used by a server-side component in a way that it could benefit an attacker, in that case the integrity is affected.
6.4. Debug, path or limited source code disclosure
For debug information, internal path or inner system working disclosures, the severity score will be set to low, unless the proof of concept shows that the obtained data can be leveraged to an attackers’ advantage.
6.5. Invalidation vulnerabilities
The ability to refresh or purge temporary resources, such as a buffer or a cache, will be scored as low by our triage team if it leads to risk for the business.
7. Updates
We may update these triage standards from time to time. The applicable version of the triage standards will always be available on the Platform.
If we make significant changes that could substantially alter the way our triage assesses or processes reports, we will inform programs participating in the triage default standards at least 15 days in advance.
An exception is made for changes that are editorial, clarifying, involve the addition of new technologies or features, or do not materially alter the way our triage processes or assesses reports. These updates may be implemented without prior notice.
Unless otherwise stated or agreed upon, updates to our triage guidelines will not retroactively apply to reports submitted prior to the date and time the changes go into effect.
Version | Publishing Date | Overview of changes |
1.0 | Nov 20th 2024 | Initial version |
1.1. | Dec 30th 2024 | Added 'unmanaged asset' section |