Reporting a Bug

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:

Section name	Description
Summary Title	This will be the title of your report. It must provide a brief overview of 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 more descriptive and helpful than “RFI Injection found.”
Target	Identifies the specific target that is 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 from the bug. The severity rating suggested by VRT is not guaranteed to be the severity rating applied to your submission once impact is considered.
Vulnerability details	Include the following information: - URL/Location of vulnerability: Location in the application where you have discovered the bug. - Description: Provide detailed information about the vulnerability. Add clear and descriptive replication steps so that the organization can easily reproduce and validate your findings. Describe the risk and the impact. 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. It is strongly recommended that 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 title 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. This field is pre-populated with text that guides you on the type and format of the information that is required. Add the description accordingly. The format includes the following key sections:
- Overview - Provide a summary of the vulnerability.
- Walkthrough and POC - Add details on how to reproduce the issue.
- Vulnerability Evidence - Provide illustrative evidence in the form of screenshots or videos that shows proof of the vulnerability.
- Demonstrated Impact - Add information about the risk and the impact of the vulnerability.
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 25,000 characters.

You can embed images and videos by dragging & dropping or pasting them. You can also click selecting link and select an image or a video that you want to embed. All video types are supported.
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.

You can attach multiple files (up to 20). Each file size must be less than 400 MB.
In Collaborate, add researchers who have collaborated on this submission. Add their user name and define the reward split between each researcher. This section is displayed only if the program is not solo. For more information about adding collaborators, see Researcher Collaboration.
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.

For detailed instructions on uploading video or images with your submissions, see improvements to file attachments.

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:

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.