bug-bounty

Vendored note (this repo). Adapted from the standalone claude-bug-bounty project. The upstream executable scaffolding — helper scripts (tools/*.py, tools/*.sh), the standalone wordlists/ pipeline, and slash-commands (/recon, /hunt, /validate, /report, …) — is not bundled here: run tooling through the MCP server (run_tool / run_pipeline / run_script) and install via the project installer/registry. Any static deep-dive files this skill needs are vendored into its own references/ folder, and cross-skill references resolve by skill name (e.g. the bb-methodology skill). Some named tools may not be in tools_config.json yet — add them with the add-tool skill or install upstream.

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