Skip to main content
Every great bug bounty payout starts with a great report. Even the most critical vulnerability can be rejected — or downgraded — if it is poorly written, lacks evidence, or fails to explain the real-world impact. This guide walks you through how to navigate to the report form, fill in every field correctly, and submit work that triagers can act on immediately.
One issue per report. Submit each security issue as a separate report. The only exception is when multiple vulnerabilities form a single, inseparable exploit chain — in that case you may combine them in one report and clearly explain how each step builds on the previous.

​
Before you start

Make sure you have:
  • Confirmed the target is in scope. Check the program’s scope table before testing. Reports targeting out-of-scope assets will be closed as Not Accepted (Out of Scope).
  • Collected your evidence. Screenshots, screen recordings, HTTP request/response logs, or PoC code should be ready before you open the form.
  • Verified reproducibility. Run through the full reproduction path at least once from scratch so your steps are accurate.

​
Step-by-step: submitting a report

1

Navigate to the program

Open the program page you want to report to. You must be an approved participant in the program — private programs require an accepted application before the Submit Report button is visible.
2

Click Submit Report

On the program page, click the Submit Report button. This opens the report creation form scoped to that program.
3

Fill in all required fields

Complete every field described in the section below. The platform will run pre-validation checks before accepting your submission — incomplete reports will be blocked at this stage.
4

Upload at least one evidence file

Use the Upload Evidences panel at the bottom of the form to drag and drop your files. You need at least one evidence file for the report to pass pre-validation.
5

Review and submit

Re-read your report before clicking Submit. Once submitted, the report enters New status and the company triage team is notified.

​
Field reference

​
Report Name

The title of your report — up to 127 characters. A good title is specific enough that a triager immediately understands what type of vulnerability it is and where it lives.

Good example

Stored XSS in profile bio field allows session hijacking

Poor example

XSS found or Security bug
Write the vulnerability class, the affected component, and the primary impact. Avoid vague titles like “Multiple issues” — that is a signal to triagers that the report may violate the one-issue rule.

​
Target

Select the affected asset from the program’s in-scope target list. Only active, in-scope targets are shown. If the asset you tested is not in the list, it is either out of scope or not yet included in the program — do not submit reports against unlisted assets.

​
CVSS Score

The report form includes a built-in CVSS calculator. Use it to score the vulnerability by setting each metric (Attack Vector, Attack Complexity, Privileges Required, User Interaction, Scope, Confidentiality, Integrity, Availability). The calculator outputs a numeric score and a vector string that are automatically attached to your report.
Be honest with your CVSS assessment. The triage team will re-evaluate the score independently. Artificially inflating CVSS to boost severity is a common mistake that damages your credibility with reviewers.
For guidance on matching CVSS scores to severity levels, see Severity & CVSS.

​
Severity

Select one of the following levels from the dropdown: The company may adjust your chosen severity during triage. This is normal and not a penalty.

​
Summary

A concise executive summary — a few sentences that capture what the vulnerability is and why it matters. Write for a non-specialist reader: a manager or legal reviewer should be able to understand the summary without reading the full technical description. Markdown is supported. You can use bold text, inline code, and short bullet lists if they improve clarity.
  • State the vulnerability class upfront (e.g., “A stored cross-site scripting vulnerability exists in…”)
  • Name the affected component or endpoint
  • Mention the highest-impact consequence in one sentence
  • Keep it under 10 sentences — save technical depth for the Description field
  • Avoid copy-pasting from OWASP or CVE descriptions; write in your own words based on what you observed

​
Description

The full technical write-up of the vulnerability. This section must include step-by-step reproduction instructions that an independent researcher could follow without any prior context. Markdown is supported. Use numbered lists for reproduction steps, code blocks for payloads and HTTP requests, and headings to separate logical sections. A strong Description answers these questions:
  1. What is the root cause of the vulnerability?
  2. Exactly how do you reproduce it? (Numbered steps, specific URLs, parameters, payloads)
  3. What environment or configuration is required? (Authenticated vs. unauthenticated, specific role, etc.)
  4. What did you observe that proves the vulnerability exists? (Error messages, unexpected responses, etc.)

​
Impact

Describe what a malicious actor could realistically do if they exploited this vulnerability. Be specific — “an attacker could read other users’ private messages” is far stronger than “there is a data exposure risk.” Markdown is supported. Consider bullet points when there are multiple distinct impact scenarios. Good impact statements cover:
  • Who is affected (single user, all users, administrators, the organization itself)
  • What data or actions are at risk (PII, financial records, authentication tokens, arbitrary code execution)
  • Realistic attack scenarios (e.g., phishing amplification, session takeover, lateral movement)
Avoid overstating impact. Claiming that a low-severity reflected XSS “could lead to full database compromise” without a realistic chain is a fast path to a downgrade or rejection.

​
Vulnerability Type (CAPEC)

Select the most appropriate CAPEC (Common Attack Pattern Enumeration and Classification) category from the dropdown. This helps the triage team categorize and route the report correctly.

​
CWE Type

Select the CWE (Common Weakness Enumeration) identifier that best matches the underlying root cause. CWE and CAPEC are complementary:
  • CWE describes the weakness in the code (e.g., CWE-79: Improper Neutralization of Input During Web Page Generation)
  • CAPEC describes the attack pattern (e.g., CAPEC-86: XSS Through HTTP Request Headers)
You can provide either or both. If you are unsure, CWE is more commonly used in vulnerability classification.

​
CVE

If a CVE identifier has already been assigned to this vulnerability (e.g., because it affects a third-party component), enter it here. This field is optional — leave it blank if no CVE exists.

​
Evidences

Upload your proof-of-concept files using the evidence uploader. The platform accepts screenshots, videos, PoC code files, and text files up to 150 MB per file. Accepted formats include .jpg, .jpeg, .png, .gif, .txt, .md, .mp4, .avi, .flv, .wmv, .mov. At least one evidence file is required. Reports without evidence will be blocked by pre-validation before submission. For detailed guidance on what makes good evidence and how to handle sensitive findings, see Evidence Guidelines.

​
Common mistakes to avoid

Skipping reproduction steps

Without clear steps, triagers cannot verify the issue. Always write steps you could hand to a stranger and have them reproduce the bug.

Multiple bugs in one report

Bundle separate issues and the whole report may be rejected. One issue, one report — except for genuine exploit chains.

Vague impact statements

“This could be dangerous” is not impact. Describe who is affected, what is at risk, and how.

No evidence

Reports without a screenshot or PoC are difficult to verify and are more likely to be rejected or deprioritized.

Out-of-scope targets

Always verify the target is listed and active in the program scope before submitting.

Overstated severity

Self-assigning Critical to every report signals poor judgment. Accurate severity self-assessments build reviewer trust.

​
Markdown support

The Summary, Description, and Impact fields all support Markdown syntax. Use it to format code blocks, create numbered lists for reproduction steps, bold key terms, and add inline code for payloads or parameter names. Well-formatted reports are faster to review and make a stronger impression.

​
After you submit

Once you click Submit, your report’s status changes to New. The company triage team receives a notification and will begin reviewing your report. You will be notified when the status changes. If the team needs more information, the status will move to Needs More Info — check the report’s comment thread and respond promptly. For a full explanation of every possible status, see Report Statuses.