Since 2017, Bugcrowd has been the maintainer of the Vulnerability Rating Taxonomy (VRT), an open-source effort to classify and prioritize submissions on the Bugcrowd Platform in an industry-standard way. The VRT is a simple-to-use, non-prescriptive, and evolving method for assigning severity levels to specific vulnerability classes. Adopting an open-source approach enables us to keep our ear to the ground, ensuring that the taxonomy stays aligned with the market. Since the VRT’s creation, hundreds of thousands of vulnerability submissions on the Bugcrowd Platform have been created, validated, triaged, and accepted by program owners under this rubric.
Over time, the attack surface and submissions associated with the VRT evolve, as do the needs of hackers and customers – so the VRT needs to grow and change, too. In that spirit, we are pleased to announce the latest release, VRT version 1.11, will be rolling out on the Bugcrowd Platform and reflected in our submission form shortly.
Overview of changes
This release includes several updates. As you can see below, they reflect changes to the threat environment, and how hackers, customers, and the Bugcrowd triage team view certain vuln classes and their relative impacts differently than before.
New Top-Level Category: Cryptographic Weaknesses
A new category has been added to cover all common flaws in the cryptography area. This approach will help guide hackers when submitting a report about a specific weakness – such as insufficient entropy, predictable PRNG or IV, missing cryptography steps, timing attacks, or insufficient key stretching, to name just a few.
Multiple Category Updates: Insecure Direct Object Reference (IDOR)
This category has been a bit of a thorn in the side of hackers for a while now as a single IDOR category with the priority of ‘Varies’ can be frustrating especially when the finding has proven demonstrated impact. Additionally, with a lack of default priority, it could mean a program owner is more exposed than they should be, compared to if it were a P1.
Therefore, we’ve added several specific variants to the category:
- P1 – Read Personal Data (PII) – Iterable Object Identifiers
- P2 – Modify/Delete Sensitive Data – Iterable Object Identifiers
- P2 – Read Personal Data (PII) – GUID/Complex Object Identifiers
- P3 – Modify/Delete Sensitive Data – GUID/Complex Object Identifiers
- P4 – Read Sensitive Data – GUID/Complex Object Identifiers
- P5 – Read Non-Sensitive Information
This change should cover most common IDOR cases. However, hackers who find something that isn’t in these specific variants can always select the top-level category and appropriate adjustments will be made by our triage team.
New Variant: HTML Injection
The existing P4 ‘Email HTML Injection’ variant receives a lot of false-positive submissions from hackers submitting HTML injection in a web application. We did a lot of research on this category, reviewing the outcomes from the P4 false positives and how many led to accepted submissions and resulted in fixes. The answer was: not very many. As a result, the new category for these is considered P5, and you’ll find it under the existing ‘Content Spoofing’ specific vulnerability name. We’ll update existing submissions under the old P4 variant to the new P5 one, accordingly.
Update To Existing Category: Server-Side Request Forgery (SSRF) – External
We reviewed a number of SSRF findings across the existing P4 variant ‘External – Low Impact’. Most of these submissions are not accepted by customers, as they typically arise from intended functionality such as a webhook or image download. As a result, we have moved this category to the P5 level.
New Specific Vulnerability: HTTP Request Smuggling
Thanks to amazing work by James Kettle at PortSwigger, this category has been revitalized across the internet. We see this vulnerability reported on a daily basis, but more often than not, it has low impact – so, we’re introducing it at the ‘Varies’ priority level in the ‘Server Security Misconfiguration’ category. The triage team will adjust affected submissions as needed.
New Specific Vulnerability: LDAP Injection
While certainly not the most reported vulnerability we see, LDAP Injection was a conspicuous omission in previous versions of VRT. We’ve remedied that by adding it to the ‘Server Side Injection’ category.
Modified Specific Vulnerability: PII Leakage
The existing ‘PII Leakage’ category is commonly misused, with many hackers simply searching for ‘PII’ in the VRT selection box and selecting this category regardless of whether the specific vulnerability is related to automotive security. As a result, the existing category under ‘Automotive Security Misconfiguration – Infotainment’ has been changed from ‘PII Leakage’ to ‘Sensitive Data Leakage/Exposure’, retaining its usability for automotive submissions specifically.
A new vulnerability called ‘PII Leakage/Exposure’ with the default priority of ‘Varies’ has also been added to the category ‘Sensitive Data Exposure’. We believe that a ‘Varies’ priority is important here because not all instances of PII – a single email address in an AEM response, for example – are a P1 by default. However, the triage team will adjust submissions to a P1 as needed.
Deprecated Specific Vulnerabilities and Variants
‘Existing P4 Cross-Site Scripting IE-Only / IE11’ has been removed and the existing P5 category ‘Cross-Site Scripting – IE Only < IE11’ modified to cover all versions of IE. These changes have been pending for some time due to Microsoft retiring Internet Explorer version 11 in 2022.
New Specific Vulnerability: On Permission Change
This vuln is documented by OWASP and other sources, but is also very use case specific. To support these customer use cases, we’ve added it to the ‘Failure to Invalidate Session’ variant of ‘Broken Authentication and Session Management.’
This is a healthy, albeit not major, update to the VRT with contributions from hackers in the Bugcrowd community, our triage team, and our customers. There is still more work to be done, so you’ll soon be hearing from us again very soon about additional changes that reflect the evolving environment.
Why contribute to the VRT?
As we said in the introduction, an open-source governance model helps the VRT evolve at a pace and in concert with the changing environment – but that only happens if hackers and customers actively participate in the process. Contributions to the repository are reviewed by the VRT Council, which meets regularly to discuss new vulnerabilities, edge cases for existing vulnerabilities, priority-level adjustments, and general validation experiences. When the team comes to a consensus regarding a proposed change, it is committed to the master.
If you would like to contribute to the VRT, Issues and Pull Requests are most welcome!
