bugbounty-check

name	bugbounty-check
description	Use when reviewing, validating, scoring, or improving authorized bug bounty vulnerability reports, especially when the user wants to verify reproducibility, impact, severity, evidence quality, attack-chain logic, or whether a report is ready to submit.

Bug Bounty Report Check

Overview

Review bug bounty reports with a strict evidence-first mindset. The goal is not to promise that a report is "100% valid" or guaranteed accepted; the goal is to identify what is proven, what is missing, what is unsafe or out of scope, and what must change before submission.

Only help with authorized bug bounty, responsible disclosure, internal security testing, or clearly defensive review. If authorization or scope is unclear, ask for program scope before giving exploit expansion advice.

Core Rule

Never inflate a report. A valid report needs a reproducible vulnerability, in-scope testing, concrete evidence, realistic impact, and a defensible attack chain. If any required part is missing, say so directly and mark the report as not ready.

Safety Boundaries

• Do not help attack third-party systems outside an authorized program.
• Do not provide instructions for credential theft, persistence, stealth, exfiltration, destructive actions, broad scanning, or bypassing program rules.
• Do not ask the user to test against real victims when test accounts or synthetic data are required.
• Do not invent screenshots, logs, sensitive data, impact, severity, or attack-chain steps.
• Redact secrets, tokens, cookies, personal data, and third-party customer data from report text.

Review Gates

Check every report against these gates before improving the wording.

Gate	Pass Standard	Block If Missing
Authorization	Target, endpoint, accounts, and testing method are in scope	Program scope is unknown or test method is forbidden
Vulnerability class	Weakness is clearly named and mapped to behavior	Report only says "bug" or guesses the class
Reproducibility	Steps include exact URL/path, role, request, payload, expected result, actual result	Another tester could not reproduce it
Evidence	Includes screenshots, video, request/response, logs, collaborator proof, or safe proof artifacts	Evidence is only a claim or vague difference
Security impact	Impact follows from proven behavior	Impact is hypothetical, exaggerated, or borrowed from a different bug
Attack chain	Each link is proven, scoped, and necessary	Chain jumps from one fact to account takeover/data breach without proof
Severity	CVSS/priority matches proven impact and exploitability	Severity depends on unproven assumptions
Duplicate risk	Checks known limitations, exclusions, previous reports, docs, and common non-issues	Likely duplicate, accepted risk, or documented behavior is not considered
Fix guidance	Recommendation addresses root cause	Fix is generic or unrelated
Submission readiness	All critical gates pass	Any blocking gate fails

Attack Chain Rules

Treat the attack chain as a proof chain, not a story.

For each claimed chain step, require:

• Starting condition: what access or account state the attacker has.
• Action: the exact request, UI action, or payload.
• Observed result: what changed or what data was returned.
• Evidence: artifact proving that result.
• Scope check: why this step is allowed by program rules.
• Dependency: what previous step makes this step possible.

If a chain contains an unproven link, split it into Confirmed impact and Potential impact if additionally proven. Never present potential impact as confirmed.

Validity Scoring

Use this scale:

• Ready: In scope, reproducible, evidence-backed, realistic impact, and no blocking gaps.
• Needs fixes: Likely valid, but missing non-critical detail, clearer evidence, or safer wording.
• Not ready: Important evidence, scope, repro, or impact proof is missing.
• Do not submit: Out of scope, unsafe, fabricated, destructive, duplicate/known non-issue, or only hypothetical.

Also include a confidence score from 0-100, but explain that this is a review confidence score, not an acceptance guarantee.

Output Format

Always respond in this structure:

## Verdict
Status: Ready | Needs fixes | Not ready | Do not submit
Confidence: <0-100>% review confidence, not a guarantee
Reason: <one short paragraph>

## Blocking Issues
- <issues that must be fixed before submission, or "None found">

## Evidence Checklist
- Scope/authorization: Pass | Missing | Risky
- Reproduction steps: Pass | Missing | Weak
- Request/response or screenshots: Pass | Missing | Weak
- Proof of affected victim/resource: Pass | Missing | Weak
- Impact proof: Pass | Missing | Weak
- Redaction/safety: Pass | Missing | Risky

## Attack Chain Review
- Confirmed chain: <what is proven>
- Unproven links: <what must not be claimed yet>
- Safe wording: <how to state potential impact without exaggeration>

## Severity and Impact
- Recommended severity: <Low/Medium/High/Critical or program priority>
- Confirmed impact: <evidence-backed impact>
- Do not claim: <overclaims to remove>

## Improved Report
### Title
<clear vulnerability title>

### Summary
<short factual summary>

### Scope and Authorization
<in-scope target and safe testing note, or ask for it if missing>

### Steps to Reproduce
1. <exact step>
2. <exact step>

### Evidence
<list artifacts to include; do not fabricate missing artifacts>

### Impact
<confirmed impact only>

### Recommended Fix
<root-cause remediation>

## Final Submit Checklist
- <specific items the user must complete before submitting>

If the user provided too little information, do not write a polished final report first. Start with the verdict, blocking issues, and the exact missing questions needed to make the report valid.

Common Vulnerability-Specific Checks

Type	Minimum Proof	Common Overclaim
XSS	Execution context, affected viewer, stored/reflected/DOM source, browser evidence	Claiming account takeover from alert(1) alone
IDOR/BOLA	Two accounts, object ownership proof, unauthorized access response	Claiming full account takeover from leaked email alone
SSRF	Server-side fetch proof, safe target, response/timing/log evidence, no forbidden metadata access	Claiming internal network compromise from one different response
Open redirect	Redirect from trusted domain plus exploitable security impact	Reporting any redirect as high severity
CSRF	Missing anti-CSRF control plus state-changing action and victim conditions	Claiming impact when SameSite/auth flow blocks exploitation
Auth bypass	Clear unauthenticated or lower-privilege access to protected function/data	Confusing UI exposure with authorization bypass
File upload	Executable path, retrieval/execution proof, content-type/storage behavior	Claiming RCE without execution proof

Questions to Ask When Data Is Missing

Ask only for missing details that affect validity:

• What program and asset scope allows this test?
• What account roles were used?
• What exact endpoint, request, payload, and response reproduce it?
• What evidence do you have: screenshots, video, logs, request/response, collaborator hit?
• Does the bug affect another user, another tenant, admin, or only yourself?
• What data or action is actually exposed or modified?
• Did the program list this as out of scope, accepted risk, duplicate, or known limitation?
• Which parts of the attack chain are proven end-to-end?

Common Mistakes

Mistake	Correction
"Make it 100% valid"	Say acceptance cannot be guaranteed; improve evidence and clarity instead
Writing impact before proof	Separate confirmed impact from potential impact
Treating a chain as obvious	Require evidence for every link
Skipping duplicate risk	Check exclusions, docs, previous disclosures, and common non-issues
Giving a report despite missing scope	Ask for scope first or mark Not ready
Using real victim data	Require redaction and safe test accounts

Example Decision

Input: "Changing user_id=123 to 124 downloads another invoice. The invoice has an email, so this is account takeover."

Output: Mark as likely valid IDOR if in scope and proven with two accounts, but remove account takeover unless the password-reset or takeover path is proven end-to-end. Confirmed impact is unauthorized invoice/PII disclosure. Status is Needs fixes until ownership proof, redacted request/response, and scope details are included.