Researcher Documentation

Welcome to the researcherdocs developer hub. You'll find comprehensive guides and documentation to help you start working with researcherdocs as quickly as possible, as well as support if you get stuck. Let's jump right in!

Get Started

Reporting a Bug

You've done the work: you've found a 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.
  • Bug type – The bug type identifies the kind of bug you have found. 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.
  • Proof of Concept – 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.

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.

Creating a Vulnerability Report

  1. From the bounty brief, click the Report Bug button.
  1. When the report form appears, enter a name for the report in the Caption field. The caption should be descriptive and concise.
  1. Choose a bug type.
  1. Continue by filling out the Bug Details: Identify the URL/Location of vulnerability, provide the Trace Dump/HTTP request, and the Proof of Concept.

Proof of Concept: Markdown Capabilities

Format the Proof of Concept field by utilizing markdown language to provide better clarity and organization within your submission report.

  1. If necessary, you may provide any additional information needed in the Any additional information field or by uploading a helpful video or screenshots
  2. Read and accept the terms and conditions.
  3. 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.

Uploading an Image or Video

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 20MB.

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

Writing a Good Bug Report

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, 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:

Review the Disclosure Policy for the Program

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


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.