- Creating a Vulnerability Report
- Saving Report as Draft
- Deleting a Saved Draft Report
- Closing Tab Before Saving Submission
- Opening Submission in Multiple Tabs
- Updating Submission on Multiple Devices
- Uploading an Image or Video
- Writing a Good Bug Report
- Review the Disclosure Policy for the Program
When you find a bug or vulnerability, you must file a report to disclose your findings.
Generally, you have to explain where the bug was found, who it affects, how to reproduce it, the parameters it affects, and provide Proof-of-Concept supporting information. You can upload any files or logs as supporting evidence. This not only helps quickly reproduce the issue but moves your submission through the review process faster, with no delays due to missing information.
The report must contain the following information at a minimum:
|Summary title||This will be the title of your report, and 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.|
|Technical Severity||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 type so that the organization understands the risk the bug presents them. The severity rating suggested by the VRT is not guaranteed to be the severity rating applied to your submission once impact has been considered.|
|Vulnerability details||This section should include the following information:
- 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: Provide additional context. Explain what it is that you have discovered and describe the risk and impact to the specific Program Owner what you discovered and describe the impact and risk.
- Screenshots or videos: Provide illustrative evidence in the form of screenshots or videos that shows proof of the vulnerability. This is one of the most impactful things you can do to provide context around your submission. We strongly recommend you provide this every time you submit.
|Attachments||Attach proof-of-concept scripts, screenshots, screen recordings, and so on.|
Note: You cannot edit a submission after it is reported.
Creating a Vulnerability Report
From the bounty brief, click Submit Report.
The report form is displayed.
In Summary title, provide a name for the report. The summary must be descriptive and concise.
Saving Report as Draft: While filling the form, you can save it as a draft so that you do not loose the information accidentally. For more information, see saving report as draft
In Target, select the target that is affected. If you do not see the target listed, choose Other.
Out of Scope Targets: Before selecting Other, see the program’s brief and make sure that the affected target is not listed as Out of Scope or does not include other similar instructions. Submitting against a target that is listed as Out of Scope will result in a -1 point adjustment. Repeatedly testing outside the approved scope will result in loss of program access or platform privileges.
Select the Technical Severity of the vulnerability. This drop-down displays the options based on VRT (Vulnerability Rating Taxonomy). You can type to filter the list by match.
In URL/Location of vulnerability, specify the location of the vulnerability, such as the URL. This is optional
In Description, describe the vulnerability and its impact. The information must be organized, clear, and descriptive so that the assigned Application Security Engineer can easily reproduce and validate your findings.
When the number of characters that you can type is 25 or fewer, a word counter is displayed warning you that you are reaching the maximum limit. It indicates the number of characters you can continue to type. The maximum limit is 10000 characters.
In Trace dump/HTTP request, provide the Trace Dump or the HTTP request. This is optional.
In Any additional information?, provide any other details about the vulnerability.
In Attachments, it is strongly recommended to upload illustrative evidence that shows proof of the vulnerability, preferably in the form of a POC video showing the vulnerability in the Program Owner’s system or screenshots at minimum.
In Confirmation, select the I have followed the program brief and agree to Bugcrowd’s terms & conditions option indicating that that you have followed all requirements of the program brief and that you agree to abide by the Bugcrowd terms and conditions.
Click Report Vulnerability to submit the report.
Bugcrowd sends you an e-mail that confirms that your submission is received.
When the status of the report changes or someone comments on your report, you will be notified through an e-mail or through your submission. Make sure that you promptly respond to any assigned blockers on your submissions, as it mean that more information is required to process your report.
Saving Report as Draft
Your submission is auto saved as a draft every 30 seconds, ensuring that it is not lost in case of connection, browser issues, or computer failure. To save the draft manually you can click Save draft at the bottom of the page. This is especially useful when you need to save some information about a submission and you do not have all the information yet to complete a submission. Once the draft submission is saved, it can be opened from another machine once authenticated without issue.
You can find your drafts using the tokenized search feature in the Submission tab or use the quick filter. For more information, see Filtering Programs.
Customers and Bugcrowd triagers will not have access to your draft submissions until you submit the report. Collaborators can be added to (and removed from) a draft submission but they will not receive an invitation to collaborate until you submit the vulnerability report. To view the submission, a collaborator must accept an invitation. Therefore, collaborators cannot view a draft submission.
For triage, submission reported time is considered and not when the draft was created.
Deleting a Saved Draft Report
When you save a draft, the Delete draft link appears next to Save draft. To delete the saved draft, click Delete draft.
A pop-up message appears asking for confirmation. Click Delete.
Once you delete a draft, it cannot be retrieved.
Closing Tab Before Saving Submission
If you try to close the Submission tab while there are unsaved changes, you will be prompted to stay on the current page.
Opening Submission in Multiple Tabs
If you open your Submission in multiple tabs within the same browser, the most recently edited submission is considered the latest, and other open tabs will display a message warning you that there is a newer version elsewhere.
Updating Submission on Multiple Devices
You cannot update a submission on two devices simultaneously and will result in changes being lost from one or both the devices. Hence, it is recommended to edit your submission on one device at a time, and make sure to close your submission when changing devices.
Uploading an Image or Video
It is important to include as much information as possible to help the person reviewing your submission understand the issue, reproduce the issue, and identify how to fix it.
Screenshots and Proof-of-Concept (POC) videos provide clear and exact replication steps for your submission. If you have recorded your session or have any file that can be used as evidence, upload it to the submission as a file attachment. All file types are supported, but individual upload size must be less than 100MB. You can upload up to five files.
Writing a Good Bug Report
When you are writing a bug report, it is important to understand the audience who will be reading your report. Bugcrowd and Program Owner Analysts may not have the same level of insight as you for the specific vulnerability. So, provide clear, concise, and descriptive information when writing your report.
Organize your information Clear explanations: Order your report in the exact progression of steps in order to replicate the vulnerability successfully.
Explain with clarity: It is so important that you write your report with purpose. Help the reader understand the security impact, replication steps, and the actions that need to be taken to address the issue, so that the submission can be processed quickly without the need for additional information.
Well documented attack scenarios: Attack scenarios indicate the impact of the vulnerability. For example: “This vulnerability affects all users of your forum. When a user signs up, and enters a username of XYZ@customer.com and a password of XYZ@customer.com, then their username is accepted. An attacker can use this vulnerability in conjunction with a username enumeration issue to brute-force forum usernames and passwords.”
For more resources on writing bug reports, see the following blogs:
- Video: Bugcrowd University - How to make a good submission
- Blog: Writing Successful Submissions
- Bug Hunter Methodology Resources
Review the Disclosure Policy for the Program
It may be tempting to share your findings with others, but remember that 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.All submissions made through the Bugcrowd platform, including Duplicates, Out of Scope, and Not Applicable submissions are covered by the Bugcrowd Standard Disclosure Terms, and vulnerability cannot be shared without permission or unless otherwise explicit stated on the Program’s brief. Program Owners may select Nondisclosure, Coordinated Disclosure, or Custom Disclosure policies, and list these on their program brief. If you do not keep vulnerability data private, it is considered an unauthorized disclosure, and may result in loss of program access or platform privileges.