Reporting a Bug

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
Info 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.

Creating a Vulnerability Report

  1. From the bounty brief, click Submit Report.

    click-submit-report

  2. When the report form appears, enter a name for the report in the Info field. The summary should be descriptive and concise.

    info

  3. Choose the target that is affected. If you do not see the target listed, choose Other.

    select-target

    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.

  4. 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.

    technical-severity

  5. Enter the location of the vulnerability, such as the URL.

    vulnerability-details

  6. Enter organized, clear, and descriptive steps to reproduce the vulnerability so that the assigned Application Security Engineer can easily reproduce and validate your findings.

    description

    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.

    description-character-limit

  7. Input a Trace Dump or the HTTP request.

    trace-dump

    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.

    add-attachment

  8. Verify that you have followed all requirements of the program brief and that you agree to abide by the Bugcrowd terms and conditions.

    check

  9. Click Report Vulnerability to submit the report.

    Bugcrowd sends you an e-mail that confirms that your submission is received.

    email

    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.

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.

Click here for detailed instructions on how to upload video or images with your submissions.

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 bruteforce 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.

program-rules


Account Management
Program Management
Submission Management
Receiving Rewards