$npx -y skills add elementalsouls/Claude-BugHunter --skill hunt-miscHunting skill for misc vulnerabilities. Built from 225 public bug bounty reports. Use when hunting misc on any target.
| 1 | ## Crown Jewel Targets |
| 2 | |
| 3 | **Why this vuln class pays:** |
| 4 | MISC vulnerabilities span access control failures, information disclosure, session/auth logic bugs, and misconfiguration — the categories that consistently produce the highest payouts because they map directly to business impact: data exposure, account takeover, privilege escalation, and infrastructure compromise. |
| 5 | |
| 6 | **Highest-value targets:** |
| 7 | - **SaaS platforms with role hierarchies** (Shopify, GitHub, GitLab) — any boundary between owner/admin/staff/guest is a privilege escalation surface |
| 8 | - **Identity/auth flows** — invitation links, password reset, SAML SSO, OAuth token scopes |
| 9 | - **Multi-tenant systems** — one tenant touching another tenant's data |
| 10 | - **Internal APIs** — LFS endpoints, pre-receive hooks, internal GraphQL/REST that assume caller is trusted |
| 11 | - **Domain/DNS management features** — transfer controls, subdomain delegation |
| 12 | - **Token/credential management** — PAT scopes, deploy keys, API tokens stored in config fields |
| 13 | |
| 14 | **Asset types that pay most:** |
| 15 | - Core product APIs (not marketing subdomains) |
| 16 | - Enterprise/self-hosted editions (GitHub Enterprise, GitLab EE) |
| 17 | - Partner/collaborator invitation systems |
| 18 | - OAuth app integrations and webhook endpoints |
| 19 | |
| 20 | --- |
| 21 | |
| 22 | ## Attack Surface Signals |
| 23 | |
| 24 | **URL patterns to watch:** |
| 25 | ``` |
| 26 | /admin/*/transfer |
| 27 | /invitations/* |
| 28 | /partners/*/accept |
| 29 | /api/v*/repos/*/lfs/* |
| 30 | /-/settings/integrations/sentry |
| 31 | /api/v*/user/installations |
| 32 | /hooks/pre-receive/* |
| 33 | /reset-password?token= |
| 34 | /auth/saml/callback |
| 35 | /api/v*/packages/pypi/* |
| 36 | ``` |
| 37 | |
| 38 | **Response header signals:** |
| 39 | ``` |
| 40 | X-Request-Id (pitchfork/Rack — check for header injection) |
| 41 | X-Shopify-Shop-Api-Call-Limit |
| 42 | X-GitLab-* |
| 43 | ``` |
| 44 | |
| 45 | **JS patterns revealing internal surfaces:** |
| 46 | ```javascript |
| 47 | // Look for hardcoded internal API paths |
| 48 | fetch('/internal/api/ |
| 49 | graphql { installations( |
| 50 | "scope": [], // empty scopes on tokens |
| 51 | "permissions": {"contents": "read"} // minimal scope PATs |
| 52 | ``` |
| 53 | |
| 54 | **Tech stack signals:** |
| 55 | - Ruby/Rack middleware (CRLF injection risk in `pitchfork`) |
| 56 | - SAML SSO enabled on enterprise instances |
| 57 | - PyPI proxy/mirror configurations (dependency confusion) |
| 58 | - Sentry error tracking integration fields (SSRF/token leak vector) |
| 59 | - Multi-role invitation systems (partners, staff, collaborators) |
| 60 | |
| 61 | --- |
| 62 | |
| 63 | ## Step-by-Step Hunting Methodology |
| 64 | |
| 65 | 1. **Map all role/permission boundaries** — enumerate every role level (owner → admin → staff → guest → removed) and document what each role *should* see |
| 66 | |
| 67 | **Marker Discipline:** when probing role boundaries by injecting unique tokens / identifiers into per-role test data, markers MUST be unique random alphanumeric strings (8+ chars, no English words, no protocol keywords). Bad markers: `test`, `marker`, `attacker`, `evil`, `admin`, `AAAA`. Good markers: `cpmark987abc`, `x4hd2k9pq`. Before claiming any reflection, search the baseline (no-marker) response for the marker — if it appears naturally, change your marker. |
| 68 | |
| 69 | **Body-Diff Rule:** a privilege-bypass claim requires response BODY differential, not status-code-only. 200 OK with byte-identical body to baseline is NOT a bypass. Always diff bodies side-by-side before claiming bypass. Status-code-only claims are the most common rejected-as-N/A category on bug-bounty platforms. |
| 70 | |
| 71 | 2. **Test invitation flows end-to-end** — accept invitations without completing verification steps; modify invitation tokens; test whether accepting an invitation as a different user grants access |
| 72 | |
| 73 | 3. **Test post-removal access** — add a user to a resource, remove them, then test if their session/token still grants access (especially after company/org removal) |
| 74 | |
| 75 | 4. **Fuzz token scope enforcement** — create PATs/tokens with minimal or no scopes, then call API endpoints that *should* require elevated scopes |
| 76 | |
| 77 | 5. **Test cross-tenant resource access** — as Tenant A, attempt to read/write Tenant B's resources by manipulating IDs, paths, or headers |
| 78 | |
| 79 | 6. **Probe internal/undocumented API endpoints** — look for LFS endpoints, internal GraphQL operations, pre-receive hook environments, webhook delivery logs |
| 80 | |
| 81 | 7. **Check SAML/SSO logic** — test signature verification bypass by stripping signatures, modifying NameID, replaying assertions, or manipulating XML namespace |
| 82 | |
| 83 | 8. **Audit configuration fields for SSRF/token exfiltration** — any URL field in admin settings (Sentry DSN, webhook URL, proxy URL) is a potential SSRF or credential leak |
| 84 | |
| 85 | 9. **Test password reset and email verification flows** — skip email verification steps; test whether reset tokens are scoped to a single user; test token reuse |
| 86 | |
| 87 | 10. **Check HTTP header injection points** — any user-controlled input passed into response headers via Ruby/Rack middleware; test CRLF sequences |
| 88 | |
| 89 | 11. **Verify DNS/subdomain hygiene** — enumerate subdomains, check for dangling CNAME records, verify SPF/DMARC/DKIM records |
| 90 | |
| 91 | 12. * |