Embed badge
Show
Style
[](https://versuz.dev/skills/shuvonsec-claude-bug-bounty-skills-triage-validation)Free SKILL.md scraped from GitHub. Clone the repo or copy the file directly into your Claude Code skills directory.
npx versuz@latest install shuvonsec-claude-bug-bounty-skills-triage-validationgit clone https://github.com/shuvonsec/claude-bug-bounty.gitcp claude-bug-bounty/SKILL.MD ~/.claude/skills/shuvonsec-claude-bug-bounty-skills-triage-validation/SKILL.md--- name: triage-validation description: Finding validation before writing any report — 7-Question Gate (all 7 questions), 4 pre-submission gates, always-rejected list, conditionally valid with chain table, CVSS 3.1 quick reference, severity decision guide, report title formula, 60-second pre-submit checklist. Use BEFORE writing any report. One wrong answer = kill the finding and move on. Saves N/A ratio. --- # TRIAGE & VALIDATION One wrong answer = STOP. Kill it. Move on. > "N/A hurts your validity ratio. Informative is neutral. Only submit what passes all 7 questions." --- ## THE 7-QUESTION GATE Ask IN ORDER. One wrong answer = STOP immediately. --- ### Q1: Can an attacker use this RIGHT NOW, step by step? Complete this template: ``` 1. Setup: I need [own account / another user's ID / no account] 2. Request: [exact HTTP method, URL, headers, body — copy-paste ready] 3. Result: I can [read / modify / delete] [exact data shown in response] 4. Impact: The real-world consequence is [account takeover / PII read / money stolen] 5. Cost: Time: [X minutes], Capital: [$0 / $X subscription required] ``` **If you CANNOT write step 2 as a real HTTP request → KILL IT.** --- ### Q2: Is the impact on the program's accepted impact list? Go to the program page. Find "Vulnerability Types" or "Out of Scope." Common tiers: - **Critical**: Any-user ATO without interaction, RCE, SQLi with data exfil, admin auth bypass - **High**: Mass PII exfil, privilege escalation, internal SSRF with data, stored XSS all users - **Medium**: IDOR on specific user non-critical data, XSS on sensitive page requiring click - **Low**: Non-sensitive info disclosure, clickjacking with PoC **If your bug maps to a listed exclusion → KILL IT.** --- ### Q3: Is the root cause in an in-scope asset? Confirm: - Vulnerable domain is on the in-scope list (not `*.internal.target.com`) - It's a production asset (not staging/dev unless explicitly in scope) - It's not a third-party service the company just uses (not Stripe, Salesforce, Google Auth) **If out-of-scope → KILL IT.** --- ### Q4: Does it require privileged access that an attacker can't realistically get? - "Admin can do X" = centralization risk = **KILL IT** (on 99% of programs) - "Non-admin can do X that only admin should do" = valid - "Requires physical access / MFA device" = usually invalid - "Requires compromised victim account to work" = questionable, low severity at best --- ### Q5: Is this already known or accepted behavior? Search: 1. Program's HackerOne/Bugcrowd disclosed reports: Ctrl+F endpoint name + bug class 2. GitHub issues on target repo: `is:issue label:security ENDPOINT_NAME` 3. Changelog/CHANGELOG.md — does it mention this behavior? 4. API docs / design docs — is it documented as intended? **If acknowledged/design decision → KILL IT.** --- ### Q6: Can you prove impact beyond "technically possible"? - XSS → show actual cookie theft or session hijack, not just `alert(1)` or `alert(document.domain)` - SSRF → hit an internal endpoint that returns data, not just DNS ping - SQLi → show actual data exfil from a real table, not just error message - IDOR → show actual other-user's data in response, not just a 200 status code **If you can only show "technically possible" → DOWNGRADE severity, not kill.** --- ### Q7: Is this a known-invalid bug class? Check the NEVER SUBMIT list below. If it's on this list without a chain → **KILL IT.** --- ### Q8: Identity check — which session found this, and does it survive? For any finding made under an authenticated hunt, record the answer to each: ``` 1. Session ID: [12-char BBHUNT_SESSION_ID hash from audit.jsonl] 2. Identity: [low-priv user A / high-priv user B / API key / etc.] 3. Anonymous repro: Does the same request work with NO auth header? 4. Cross-identity: Does it work under session B with the same data scope? 5. Stale-cred repro: Does a logged-out / expired session still get the data? ``` Why this matters: - **IDOR / BOLA**: must work with session A reading session B's data — if it only works with no auth, that's "missing auth" not IDOR (different bug, different severity). - **Priv-esc**: must work with low-priv session reading high-priv data — if both sessions can already see it, no bug. - **Auth bypass**: must work *without* a valid session — if it stops working when you log out, you've found a permissions issue, not a bypass. - **Always check both directions**: a finding that only reproduces under one identity is often a real, scoped permission boundary, not a vuln. `audit.jsonl` entries are tagged with `session_id`. Re-run the request under each identity and confirm the bug holds before writing the report. This is the most common reason "confirmed IDOR" findings come back as N/A. --- --- ## 4 PRE-SUBMISSION GATES Run in sequence. ALL 4 must PASS. ### Gate 0: Reality Check (30 seconds) ``` [ ] Bug is REAL — confirmed with actual HTTP requests, not code reading alone [ ] Bug is IN SCOPE — checked program scope page explicitly [ ] Reproducible from scratch — can reproduce starting from fresh session [ ] Evidence ready — screenshot, response body, or video ``` ### Gate 1: Impact Validation (2 minutes) ``` [ ] Can answer: "What can attacker DO that they couldn't before?" [ ] Answer is more than "see non-sensitive data" (unless program pays for info disclosure) [ ] Real victim: another user's data, company's data, financial loss [ ] Not relying on victim doing something unlikely ``` ### Gate 2: Deduplication Check (5 minutes) ``` [ ] Searched HackerOne Hacktivity for this program + similar bug title/endpoint [ ] Searched GitHub issues for target repo [ ] Read most recent 5 disclosed reports for this program [ ] Not a "known issue" in their changelog or public docs [ ] Google: "TARGET_NAME ENDPOINT_NAME bug bounty" ``` ### Gate 3: Report Quality (10 minutes) ``` [ ] Title: [Bug Class] in [Endpoint] allows [actor] to [impact] [ ] Steps to Reproduce: copy-pasteable HTTP request [ ] Evidence: screenshot/video of actual impact (not just 200 status) [ ] Severity: matches CVSS 3.1 score AND program's severity definitions [ ] Remediation: 1-2 sentences of concrete fix [ ] NEVER used "could potentially" or "may allow" ``` --- ## NEVER SUBMIT LIST Submitting these destroys your validity ratio. ``` Missing CSP / HSTS / security headers Missing SPF / DKIM / DMARC GraphQL introspection alone (no auth bypass, no IDOR demonstrated) Banner / version disclosure without working CVE exploit Clickjacking on non-sensitive pages (no sensitive action PoC) Tabnabbing CSV injection (no actual code execution shown) CORS wildcard (*) without credential exfil proof of concept Logout CSRF Self-XSS (only exploits own account) Open redirect alone (no ATO or OAuth theft chain) OAuth client_secret in mobile app (known, expected) SSRF DNS callback only (no internal service access or data) Host header injection alone (no password reset poisoning PoC) Rate limit on non-critical forms (search, contact, login with Cloudflare) Session not invalidated on logout Concurrent sessions Internal IP in error message Mixed content SSL weak ciphers Missing HttpOnly / Secure cookie flags alone Broken external links Autocomplete on password fields Pre-account takeover (usually — very specific conditions required) ``` --- ## CONDITIONALLY VALID — CHAIN REQUIRED Build the chain first, prove it works end to end, THEN report. | Standalone Finding | Chain Required | Valid Result | |---|---|---| | Open redirect | + OAuth redirect_uri → auth code theft | ATO (Critical) | | Clickjacking | + sensitive action + working PoC | Medium | | CORS wildcard | + credentialed request exfils user PII | High | | CSRF | + sensitive action (transfer funds, change email, delete account) | High | | Rate limit bypass | + OTP/reset token brute force succeeds | Medium/High | | SSRF DNS-only | + internal service access + data returned | Medium | | Host header injection | + password reset email uses injected host | High | | Prompt injection | + reads other user's data (IDOR) | High | | S3 bucket listing | + JS bundles contain API keys or OAuth secrets | Medium/High | | Self-XSS | + CSRF to trigger it on victim without their knowledge | Medium | | Subdomain takeover | + OAuth redirect_uri registered at that subdomain | Critical | | GraphQL introspection | + auth bypass mutation or IDOR on node() | High | --- ## CVSS 3.1 QUICK REFERENCE ### Common Score Examples | Finding | Score | Severity | Vector | |---|---|---|---| | IDOR read PII, any user, auth required | 6.5 | Medium | AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N | | IDOR write/delete, any user | 7.5 | High | AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N | | Auth bypass → admin panel | 9.8 | Critical | AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H | | Stored XSS → cookie theft, stored | 8.8 | High | AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N | | SQLi → full DB dump | 8.6 | High | AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N | | SSRF → cloud metadata | 9.1 | Critical | AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N | | Race → double spend | 7.5 | High | AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N | | GraphQL auth bypass | 8.7 | High | AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N | | JWT none algorithm | 9.1 | Critical | AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H | ### Metric Quick Guide | What you have | Metric | Value | |---|---|---| | Exploitable over internet | AV | Network (N) | | No special timing or race | AC | Low (L) | | Free account needed | PR | Low (L) | | No login needed | PR | None (N) | | Admin needed | PR | High (H) | | No victim action | UI | None (N) | | Victim must click | UI | Required (R) | | Reads all data | C | High (H) | | Reads some data | C | Low (L) | | Modifies all data | I | High (H) | | Crashes service | A | High (H) | | Affects only app | S | Unchanged (U) | | Affects browser/OS/cloud | S | Changed (C) | --- ## KILL FAST RULES The goal is to QUICKLY disqualify bad leads so you hunt real bugs: 1. **5-minute rule**: If you can't fill in Q1's template in 5 minutes → move on 2. **Precondition count**: More than 2 preconditions simultaneously required → kill it 3. **Impact test**: "What does attacker walk away with?" — if nothing tangible → kill it 4. **Admin bypass**: "Admin can do X" is NEVER a bug → kill it immediately 5. **Design doc test**: If it's documented behavior → kill it immediately 6. **Rabbit hole signal**: 30+ min on Q6 with no reproducible PoC → kill it --- ## ANTI-PATTERNS THAT LOSE MONEY ``` Writing a report before confirming the bug exists (most common) Submitting theoretical impact without proof "The API returns more fields than necessary" (sensitivity matters — is it actually sensitive?) Chaining A+B into one report when they're separate bugs (two separate payouts) Reporting B saying "similar to A in my other report" — fresh Gate 0 for every bug Overclaiming severity — triagers trust you less next time Under-describing impact — triager doesn't understand why it matters ```