For hackers
Write reports developers can reproduce.
A good VibeBounty report is short, specific, and backed by evidence. The goal is to prove impact without creating unnecessary risk for the product owner.
Before you submit
- 1Read the program scopeOnly test assets listed by the developer. If a domain, API, mobile app, or account type is not listed, treat it as out of scope.
- 2Confirm the bug is realA report should include a reproducible path, not just a scanner warning, stack trace, suspicious header, or theoretical issue.
- 3Limit the blast radiusUse your own accounts, avoid persistence, avoid destructive actions, and stop as soon as you can prove impact.
What to include
Target
The affected URL, endpoint, method, parameter, account role, and any required setup conditions.
Steps
A numbered reproduction path that a developer can follow without guessing what you clicked or changed.
Impact
The concrete outcome: data accessed, action performed, account boundary crossed, or money flow affected.
Evidence
Screenshots, request and response excerpts, short videos, or harmless proof values that show the issue.
Suggested severity
Use the program payout table and CVSS primer as a guide, then explain any context that changes severity.
Fix hint
Optional, but useful when the root cause is obvious. Keep it practical and avoid long generic advice.
Reports that look copied, vague, duplicated, or generated without testing may be blocked by quality gates and can reduce your ability to submit future reports.