gabson0x/bountyforge/bug-bounty

Claude Code and agent skill by gabson0x/bountyforge

Trust tier 2
  • community
LLM review pending
Source check pending

Checking that the SKILL.md file is still in the repository.

Complete bug bounty workflow — recon (subdomain enumeration, asset discovery, fingerprinting, HackerOne scope, source code audit), pre-hunt learning (disclosed reports, tech stack research, mind maps, threat modeling), vulnerability hunting (IDOR, SSRF, XSS, auth bypass, CSRF, race conditions, SQLi, XXE, file upload, business logic, GraphQL, HTTP smuggling, cache poisoning, OAuth, timing side-channels, OIDC, SSTI, subdomain takeover, cloud misconfig, ATO chains, agentic AI), LLM/AI security testing (chatbot IDOR, prompt injection, indirect injection, ASCII smuggling, exfil channels, RCE via code tools, system prompt extraction, ASI01-ASI10), A-to-B bug chaining (IDOR→auth bypass, SSRF→cloud metadata, XSS→ATO, open redirect→OAuth theft, S3→bundle→secret→OAuth), bypass tables (SSRF IP bypass, open redirect bypass, file upload bypass), language-specific grep (JS prototype pollution, Python pickle, PHP type juggling, Go template.HTML, Ruby YAML.load, Rust unwrap), and reporting (7-Question Gate, 4 validation gates, human-tone writing, templates by vuln class, CVSS 3.1, PoC generation, always-rejected list, conditional chain table, submission checklist). Use for ANY bug bounty task — starting a new target, doing recon, hunting specific vulns, auditing source code, testing AI features, validating findings, or writing reports. 中文触发词:漏洞赏金、安全测试、渗透测试、漏洞挖掘、信息收集、子域名枚举、XSS测试、SQL注入、SSRF、安全审计、漏洞报告

Install

npx vskill@latest install gabson0x/bountyforge/bug-bounty

SKILL.md

Bug Bounty Master Workflow

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

See also: [[Trust Map]], [[Methodology]], [[Vuln Classes]], [[A→B Chains]], [[Triage]], [[Report Writing]]

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:
PatternKill 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 itNot reachable = not a bug
Source maps without secretsNo impact
SSRF with DNS-only callbackNeed data exfil or internal access
Open redirect aloneNeed 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 `skills/bb-methodology/SKILL.md`.

AUTH-AWARE HUNTING (when bugs live behind a login)

Anonymous recon misses the bugs that pay most. IDOR, BOLA, mass-assignment, privilege escalation, auth bypass, SSRF behind login, and most LLM/agent bugs are invisible until you log in. Load auth once at session start and every downstream tool (httpx, katana, ffuf, nuclei, dalfox, the SQLi / SSTI / upload PoC verifiers) sends those headers automatically.

bash
# Pick ONE of these and run hunt.py normally:
python3 tools/hunt.py --target T --cookie 'session=eyJabc...'
python3 tools/hunt.py --target T --bearer 'eyJhbGciOi...'
python3 tools/hunt.py --target T --auth-file .private/T.json
# Or via env (persists for the shell):
export BBHUNT_COOKIE='session=eyJabc...'
python3 tools/hunt.py --target T

For IDOR / BOLA hunts, load two sessions and diff behavior:

bash
python3 tools/hunt.py --target T --auth-file .private/T-user-a.json
python3 tools/hunt.py --target T --auth-file .private/T-user-b.json
# Audit log entries carry different session_id hashes → diff which
# endpoints behaved differently per identity.

Safety: cookies/tokens never appear in logs, hunt-memory, or repr(). Only a 12-char session_id hash is recorded. .private/ is gitignored. MFA-skip and SAML signature-stripping probes deliberately stay anonymous — that's the attack they're checking for.

Full guide: docs/auth-sessions.md. Template: docs/auth.example.json.


TEMP EMAIL WORKFLOW (Essential for Multi-Account Testing)

Anonymous recon misses the bugs that require multiple accounts. IDOR, privilege escalation, and business logic bugs need at least two accounts. Create temp emails BEFORE you start hunting.

Quick Setup
bash
# Mail.tm API (free, no registration, fully programmatic)
create_temp_email() {
DOMAIN=$(curl -s https://api.mail.tm/domains | jq -r '.[0].domain')
EMAIL="hunter_$(date +%s)@${DOMAIN}"
PASSWORD="TempPass123!"
curl -s -X POST https://api.mail.tm/accounts \
-H "Content-Type: application/json" \
-d "{\"address\":\"$EMAIL\",\"password\":\"$PASSWORD\"}"
echo "$EMAIL"
}
# Create 3 accounts for comprehensive testing
for i in 1 2 3; do
EMAIL=$(create_temp_email)
echo "Account $i: $EMAIL"
done
Multi-Account Testing Workflow
BEFORE HUNTING:
1. Create temp email #1 → register "attacker" account (low priv)
2. Create temp email #2 → register "victim" account (another user)
3. Create temp email #3 → register additional test account
4. Complete email verification for all accounts
5. Login to all accounts in Burp (different containers/profiles)
WHILE HUNTING:
- Test IDOR: Account A requests with Account B's resource IDs
- Test privilege escalation: Account A tries admin endpoints
- Test business logic: Account A manipulates Account B's data
- Test race conditions: Both accounts perform same action simultaneously
- Test auth bypass: Access protected routes without tokens
AFTER FINDING A BUG:
- Quantify: "This affects all N users" (use temp email count as proof)
- Chain: Combine low-severity bugs for higher impact
- Document: Which accounts were used, what data was accessed
IDOR Testing with Temp Emails
bash
# Step 1: Create two temp emails
EMAIL_A="hunter_$(date +%s)@$(curl -s https://api.mail.tm/domains | jq -r '.[0].domain')"
EMAIL_B="victim_$(date +%s)@$(curl -s https://api.mail.tm/domains | jq -r '.[0].domain')"
# Step 2: Register both accounts on target
# Account A: attacker (low privilege)
# Account B: victim (another user)
# Step 3: Login to both accounts in Burp
# Account A → Burp Container 1
# Account B → Burp Container 2
# Step 4: As Account A, perform actions and note all IDs
# Example: GET /api/v1/users/123/orders → order IDs: 456, 789
# Example: GET /api/v1/users/123/profile → user ID: 123
# Step 5: As Account A, try to access Account B's resources
# Change user_id in request: /api/v1/users/456/orders
# If Account A can see Account B's orders = IDOR
# Step 6: Document the finding
# "Account A (attacker@test.com) can access Account B (victim@test.com)
# resources by changing user_id parameter from 123 to 456"
# "This affects all users on the platform"
Privilege Escalation Testing
bash
# Step 1: Create temp email for regular user
EMAIL_USER="user_$(date +%s)@$(curl -s https://api.mail.tm/domains | jq -r '.[0].domain')"
# Step 2: Register as regular user (no admin privileges)
# Step 3: Test admin endpoints
# Try accessing admin-only endpoints with regular user token
curl -s -H "Authorization: Bearer $REGULAR_USER_TOKEN" \
https://target.com/api/admin/users
# If 200 response = privilege escalation
# Step 4: Test role manipulation
# In registration or profile update, try adding role parameter
curl -s -X POST https://target.com/api/register \
-H "Content-Type: application/json" \
-d '{"email":"user@test.com","password":"pass","role":"admin"}'
# If accepted = mass assignment vulnerability
# Step 5: Test admin panel access
# Try accessing /admin, /dashboard, /panel with regular user
curl -s -H "Authorization: Bearer $REGULAR_USER_TOKEN" \
https://target.com/admin
# If 200 response = admin panel accessible
Business Logic Testing
bash
# Step 1: Create two temp emails for different user types
EMAIL_FREE="free_$(date +%s)@$(curl -s https://api.mail.tm/domains | jq -r '.[0].domain')"
EMAIL_PAID="paid_$(date +%s)@$(curl -s https://api.mail.tm/domains | jq -r '.[0].domain')"
# Step 2: Register free account and paid account
# Free: limited features
# Paid: full access
# Step 3: Test as free user trying paid features
# Example: Free user tries to access premium API endpoint
curl -s -H "Authorization: Bearer $FREE_USER_TOKEN" \
https://target.com/api/premium/data
# If 200 response = business logic bypass
# Step 4: Test price manipulation
# Example: Free user tries to purchase at discounted price
curl -s -X POST https://target.com/api/purchase \
-H "Authorization: Bearer $FREE_USER_TOKEN" \
-H "Content-Type: application/json" \
-d '{"item":"premium","price":0}'
# If accepted = price manipulation vulnerability
Race Condition Testing
bash
# Step 1: Create two temp emails
EMAIL_RACE1="race1_$(date +%s)@$(curl -s https://api.mail.tm/domains | jq -r '.[0].domain')"
EMAIL_RACE2="race2_$(date +%s)@$(curl -s https://api.mail.tm/domains | jq -r '.[0].domain')"
# Step 2: Register both accounts
# Step 3: Simultaneous requests from both accounts
# Example: Both accounts try to redeem same coupon
curl -s -X POST https://target.com/api/redeem \
-H "Authorization: Bearer $RACE1_TOKEN" \
-d '{"code":"PROMO10"}' &
curl -s -X POST https://target.com/api/redeem \
-H "Authorization: Bearer $RACE2_TOKEN" \
-d '{"code":"PROMO10"}' &
wait
# If both succeed = race condition = double spend
Password Reset Testing with Temp Emails
bash
# 1. Register with temp email
# 2. Trigger password reset
# 3. Fetch reset token from temp email API
TOKEN=$(curl -s "https://api.mail.tm/messages" \
-H "Authorization: Bearer $TOKEN" | jq -r '.[0].text' | grep -oP 'token=\K[^"&]+')
# 4. Test: Can you use reset from different IP?
# 5. Test: Does token expire? (request new, try old)
# 6. Test: Can you brute force weak tokens?
# 7. Test: Does reset link leak in Referer header?
Temp Email Providers
ProviderAPIFreeNotes
Mail.tmREST APIYesBest for automation
Guerrilla MailWeb/APIYesGood for manual testing
YopmailWebYesPersistent inboxes
TempailWebYesSimple interface
MailinatorAPILimitedGood for testing
FakeMailWebYesNo registration
Quick Email Verification Bypass
bash
# Some sites require email verification before account is active
# Temp emails can fetch verification links programmatically
# Mail.tm verification
TOKEN=$(curl -s -X POST https://api.mail.tm/token \
-H "Content-Type: application/json" \
-d '{"address":"'$EMAIL'","password":"TempPass123!"}' | jq -r '.token')
# Fetch messages
curl -s "https://api.mail.tm/messages" \
-H "Authorization: Bearer $TOKEN" | jq '.[0].text'
# Extract verification link
VERIFY_URL=$(curl -s "https://api.mail.tm/messages" \
-H "Authorization: Bearer $TOKEN" | jq -r '.[0].text' | grep -oP 'https?://\S+verify\S+')
# Visit verification link
curl -s "$VERIFY_URL"

DEEPER RESEARCH (Never Hunt Blind)

Before touching any tool, spend 15-20 minutes understanding the target. This is what separates top 1% hunters from the rest.

Required Pre-Hunt Research (Do ALL of These)

This is the start of the file. Read the full SKILL.md on GitHub.

Security

  • Security scanPassed, 93 of 100Pattern checks on the skill's files.
  • Model reviewNot runA model review is scheduled for the next rescan.

Quality evaluation

  • Task evaluationNot runNo evaluation yet. Run one in Skill Studio.

Source

Popularity

Repository stars
431
Repository forks
54
7-day trend score
30

Stars and forks are for the whole GitHub repository, not this skill alone. Not refreshed yet.

Works with

Any agent vskill installs to: 56 targets in all. These 39 have a page on this site.

  • Claude Code
  • Cursor
  • GitHub Copilot
  • Windsurf
  • Codex
  • Gemini CLI
  • Cline
  • Amp
  • Roo Code
  • Goose
  • Continue
  • Kilo Code
  • Junie
  • Trae
  • OpenHands
  • Qwen Code
  • AI Agent
  • Tabnine Chat
  • Sourcegraph Cody
  • Amazon Q
  • Firebase Genkit
  • Sweep
  • Devin
  • Phind
  • Mentat
  • Claude Desktop
  • Aider
  • GPT Pilot
  • Plandex
  • bolt.new
  • v0
  • Replit Agent
  • Anse
  • TypingMind
  • BetterChatGPT
  • LibreChat
  • Warp AI
  • Pieces
  • Fig AI
Embed badge
vskill VERIFIED badge
[![vskill VERIFIED](https://verified-skill.com/api/v1/skills/gabson0x/bountyforge/bug-bounty/badge)](https://verified-skill.com/skills/gabson0x/bountyforge/bug-bounty)

Something wrong with this skill or its page? Tell us.