You've done the work: you've found a bug or vulnerability. Now, it's time to file a report to disclose your findings.
Here's what the report should contain, at a minimum:
- Caption – The title of the report should describe the type of bug found, where it was found, and the overall impact. For example, “Remote File Inclusion in Resume Upload Form allows remote code execution” is much more descriptive and helpful than “RFI Injection found."
- Target - The Target field identifies the specific target affected by the bug you have found.
- Vulnerability Rating Taxonomy Classification – The Vulnerability Rating Taxonomy Classification identifies the kind of bug you have found based on our VRT, our baseline priority rating system for common bugs found on bug bounty programs. It is important that you choose the correct bug type so that the organization understands the risk the bug presents them.
- Bug URL – The bug URL identifies the location in the application where you discovered the bug.
- Description – Your report must include clear and descriptive replication steps so that the organization can easily reproduce and validate that your findings.
- Additional information – The section where you can provide context. You can explain what you discovered and describe the impact and risk of your discovery.
- Screenshots or videos – If possible, you should include illustrative evidence that shows proof of the vulnerability.
Some bugs will require additional information. Some will require less. It depends on the type of bug that you are reporting.
Generally, you'll need to explain where the bug is, who it affects, how to reproduce it, the parameters it affects, and any PoC code. You can also upload any files that you may have that proves the vulnerability exists. You want to add as much information as you can to help reproduce the vulnerability. This not only helps the company quickly reproduce the issue but also helps moves your submission through the review process a lot faster.
- From the bounty brief, click the Report Bug button.
- When the report form appears, enter a name for the report in the Caption field. The caption should be descriptive and concise.
- Choose the target that is affected, if you do not see the target listed choose "Other".
NOTE: Out of Scope Targets
Before selecting other, take another look at the program scope and be sure that the target affected is not listed as "Out of Scope".
- Select the Technical Severity of the vulnerability, this drop-down list is based on our VRT (Vulnerability Rating Taxonomy).
- Enter the location of the vulnerability, such as the URL.
- Enter organized, clear, and descriptive replication steps so that the organization can easily reproduce and validate that your findings.
- Input Trace Dump or the HTTP request.
- If possible, we always recommend uploading illustrative evidence that shows proof of the vulnerability.
- Read and accept the terms and conditions.
- When you are done, click the Report Bug button to submit the report.
After you submit your report, Bugcrowd sends you an e-mail that confirms that we've received your submission.
When the status of the report changes or someone comments on your report, you will be notified via e-mail or through your submission.
It's important to include as much information as possible to help the person reviewing your submission understand the issue, reproduce the issue, and identify how they can fix it.
Screenshots and videos are great because they can provide clear and exact replication steps and PoC for your submission. If you have recorded your session or have any file that can be used as evidence, please upload it to the submission as a file attachment. All file types are supported up to 50MB. You may upload up to 5 files.
When you're writing a bug report, it is important that you remember your audience. You must remember that you don't know who is going to read your report. You can't expect them to have the same level of insight as you do, so you need to guide them through your findings using clear, concise, and descriptive language. On top of that, you must organize your information so that it makes sense logically.
Clear explanations – It is so important that you write your report clearly and with purpose. The goal is to help the reader understand the security impact, replication steps, and the actions that need to be taken to address the issue.
Well documented attack scenarios – Attack scenarios tell the program owner why they should care the vulnerability. For example, you can say something like, "This vulnerability affects all users of your forum. When a user signs up, and enters a username of XYZ@Customer.comand a password of XYZ@Customer.com, then his username is accepted. An attacker could use this vulnerability in conjunction with a username enumeration issue to bruteforce forum usernames and passwords."
For more resources on writing bug reports, check out the following blogs:
It may be tempting to share your findings with others, but remember, each program has a disclosure policy that you must respect. Some programs do not want you to share the vulnerabilities that you've discovered with the public.
For more information on disclosure policies for Bugcrowd programs, please see our Public Disclosure Policy
The existence or details of private or invitation-only programs must not be communicated to anyone who is not a Bugcrowd employee or an authorized employee of the organization responsible for the program.