Security Bounty Hunter
Hunt remotely exploitable, bounty-eligible vulnerabilities in a codebase when you need payable findings—not a generic lint of best practices.
Overview
Security Bounty Hunter is an agent skill most often used in Ship (also Operate infra review) that hunts exploitable, remotely reachable vulnerabilities suited for bounty or responsible disclosure.
Install
npx skills add https://github.com/affaan-m/everything-claude-code --skill security-bounty-hunterWhat is this skill?
- Biased toward remotely reachable, user-controlled attack paths
- In-scope pattern table: SSRF, auth bypass, deserialization RCE, SQLi, command injection, path traversal
- Explicitly deprioritizes noisy local-only findings platforms reject
- Framed for Huntr, HackerOne, and similar responsible disclosure workflows
- Version 1.0.0 ECC direct-port adaptation
- 6 in-scope vulnerability pattern rows in the reference table
Adoption & trust: 3.2k installs on skills.sh; 210k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You cannot tell which repo issues are bounty-worthy versus informative noise before you waste hours on a rejected report.
Who is it for?
Builders preparing Huntr or HackerOne submissions or pre-release scans on internet-facing code.
Skip if: Org-wide compliance audits, dependency-only scans without exploit paths, or legal approval of disclosure without reading program scope.
When should I use this skill?
Scanning a repository for exploitable vulnerabilities or preparing a bounty submission where payability matters more than theoretical unsafe code.
What do I get? / Deliverables
You get a prioritized focus on in-scope, user-reachable vulnerability patterns with CWE-aligned impact instead of a generic secure-coding lecture.
- Prioritized list of remotely reachable vulnerability candidates
- CWE-aligned pattern matches with typical impact notes
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Bounty-focused triage is canonically Ship security work before you trust external exposure or submit reports. Security subphase covers deliberate vulnerability discovery with disclosure or bounty intent.
Where it fits
Scan upload and webhook handlers for SSRF and command injection before public launch.
Decide if middleware auth gaps are exploitable enough to file versus fix silently.
Re-run focused patterns after exposing a new admin API behind a reverse proxy.
How it compares
Exploitability-first bounty triage—not a broad code review quality skill or secrets linter.
Common Questions / FAQ
Who is security-bounty-hunter for?
Solo developers and small teams who need practical, payable vulnerability leads in repositories they can test responsibly.
When should I use security-bounty-hunter?
In Ship before launch on exposed APIs; when triaging a repo for bounty eligibility; in Operate when investigating whether a production bug class is remotely triggerable.
Is security-bounty-hunter safe to install?
It guides offensive-style code analysis in your workspace—review the Security Audits panel on this page and only test systems you are authorized to assess.
SKILL.md
READMESKILL.md - Security Bounty Hunter
# Security Bounty Hunter Use this when the goal is practical vulnerability discovery for responsible disclosure or bounty submission, not a broad best-practices review. ## When to Use - Scanning a repository for exploitable vulnerabilities - Preparing a Huntr, HackerOne, or similar bounty submission - Triage where the question is "does this actually pay?" rather than "is this theoretically unsafe?" ## How It Works Bias toward remotely reachable, user-controlled attack paths and throw away patterns that platforms routinely reject as informative or out of scope. ## In-Scope Patterns These are the kinds of issues that consistently matter: | Pattern | CWE | Typical impact | | --- | --- | --- | | SSRF through user-controlled URLs | CWE-918 | internal network access, cloud metadata theft | | Auth bypass in middleware or API guards | CWE-287 | unauthorized account or data access | | Remote deserialization or upload-to-RCE paths | CWE-502 | code execution | | SQL injection in reachable endpoints | CWE-89 | data exfiltration, auth bypass, data destruction | | Command injection in request handlers | CWE-78 | code execution | | Path traversal in file-serving paths | CWE-22 | arbitrary file read or write | | Auto-triggered XSS | CWE-79 | session theft, admin compromise | ## Skip These These are usually low-signal or out of bounty scope unless the program says otherwise: - Local-only `pickle.loads`, `torch.load`, or equivalent with no remote path - `eval()` or `exec()` in CLI-only tooling - `shell=True` on fully hardcoded commands - Missing security headers by themselves - Generic rate-limiting complaints without exploit impact - Self-XSS requiring the victim to paste code manually - CI/CD injection that is not part of the target program scope - Demo, example, or test-only code ## Workflow 1. Check scope first: program rules, SECURITY.md, disclosure channel, and exclusions. 2. Find real entrypoints: HTTP handlers, uploads, background jobs, webhooks, parsers, and integration endpoints. 3. Run static tooling where it helps, but treat it as triage input only. 4. Read the real code path end to end. 5. Prove user control reaches a meaningful sink. 6. Confirm exploitability and impact with the smallest safe PoC possible. 7. Check for duplicates before drafting a report. ## Example Triage Loop ```bash semgrep --config=auto --severity=ERROR --severity=WARNING --json ``` Then manually filter: - drop tests, demos, fixtures, vendored code - drop local-only or non-reachable paths - keep only findings with a clear network or user-controlled route ## Report Structure ```markdown ## Description [What the vulnerability is and why it matters] ## Vulnerable Code [File path, line range, and a small snippet] ## Proof of Concept [Minimal working request or script] ## Impact [What the attacker can achieve] ## Affected Version [Version, commit, or deployment target tested] ``` ## Quality Gate Before submitting: - The code path is reachable from a real user or network boundary - The input is genuinely user-controlled - The sink is meaningful and exploitable - The PoC works - The issue is not already covered by an advisory, CVE, or open ticket - The target is actually in scope for the bounty program