bug-bounty

> **⚠️ AUTHORIZED USE ONLY**

> This skill is for educational purposes or authorized security assessments only.

> You must have explicit, written permission from the system owner before using this tool.

> Misuse of this tool is illegal and strictly prohibited.

> **Mandatory confirmation gate**

> Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:

> 1. Ask the user to state the exact target URL, IP, account, or resource.

> 2. Ask the user to confirm written authorization and the permitted scope.

> 3. Show the exact command(s) and explain their expected effect.

> 4. Wait for explicit confirmation in the current conversation.

>

> Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.

# Bug Bounty Master Workflow

Full pipeline: Recon -> Learn -> Hunt -> Validate -> Report. One skill for everything.

THE ONLY QUESTION THAT MATTERS

> **"Can an attacker do this RIGHT NOW against a real user who has taken NO unusual actions -- and does it cause real harm (stolen money, leaked PII, account takeover, code execution)?"**

>

> If the answer is NO -- **STOP. Do not write. Do not explore further. Move on.**

Theoretical Bug = Wasted Time. Kill These Immediately:

| Pattern | Kill Reason |

|---|---|

| "Could theoretically allow..." | Not exploitable = not a bug |

| "An attacker with X, Y, Z conditions could..." | Too many preconditions |

| "Wrong implementation but no practical impact" | Wrong but harmless = not a bug |

| Dead code with a bug in it | Not reachable = not a bug |

| Source maps without secrets | No impact |

| SSRF with DNS-only callback | Need data exfil or internal access |

| Open redirect alone | Need ATO or OAuth chain |

| "Could be used in a chain if..." | Build the chain first, THEN report |

**You must demonstrate actual harm. "Could" is not a bug. Prove it works or drop it.**

---

CRITICAL RULES

1. **READ FULL SCOPE FIRST** -- verify every asset/domain is owned by the target org

2. **NO THEORETICAL BUGS** -- "Can an attacker steal funds, leak PII, takeover account, or execute code RIGHT NOW?" If no, STOP.

3. **KILL WEAK FINDINGS FAST** -- run the 7-Question Gate BEFORE writing any report

4. **Validate before writing** -- check CHANGELOG, design docs, deployment scripts FIRST

5. **One bug class at a time** -- go deep, don't spray

6. **Verify data isn't already public** -- check web UI in incognito before reporting API "leaks"

7. **5-MINUTE RULE** -- if a target shows nothing after 5 min probing (all 401/403/404), MOVE ON

8. **IMPACT-FIRST HUNTING** -- ask "what's the worst thing if auth was broken?" If nothing valuable, skip target

9. **CREDENTIAL LEAKS need exploitation proof** -- finding keys isn't enough, must PROVE what they access

10. **STOP SHALLOW RECON SPIRALS** -- don't probe 403s, don't grep for analytics keys, don't check staging domains that lead nowhere

11. **BUSINESS IMPACT over vuln class** -- severity depends on CONTEXT, not just vuln type

12. **UNDERSTAND THE TARGET DEEPLY** -- before hunting, learn the app like a real user

13. **DON'T OVER-RELY ON AUTOMATION** -- automated scans hit WAFs, trigger rate limits, find the same bugs everyone else finds

14. **HUNT LESS-SATURATED VULN CLASSES** -- XSS/SSRF/XXE have the most competition. Expand into: cache poisoning, Android/mobile vulns, business logic, race conditions, OAuth/OIDC chains, CI/CD pipeline attacks

15. **ONE-HOUR RULE** -- stuck on one target for an hour with no progress? SWITCH CONTEXT

16. **TWO-EYE APPROACH** -- combine systematic testing (checklist) with anomaly detection (watch for unexpected behavior)

17. **T-SHAPED KNOWLEDGE** -- go DEEP in one area and BROAD across everything else

> **For the full hunting methodology** — 5-phase non-linear workflow, developer psychology framework, session discipline, tool routing by phase, and Wide/Deep route selection — see **`sk