Security bounty hunter

Skill asong56/skills/04-assure/security-bounty-hunter

Hunt for exploitable, bounty-worthy security issues in repositories. Focuses on remotely reachable vulnerabilities that qualify for real reports instead of noisy local-only findings.From its SKILL.md

Install

npx -y skills add asong56/skills --skill security-bounty-hunter

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

21 days oldThe repository was created 21 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.4 KB, 713 tokens by cl100k_base, as published. Nobody here has run it

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

Check scope first: program rules, SECURITY.md, disclosure channel, and exclusions.
Find real entrypoints: HTTP handlers, uploads, background jobs, webhooks, parsers, and integration endpoints.
Run static tooling where it helps, but treat it as triage input only.
Read the real code path end to end.
Prove user control reaches a meaningful sink.
Confirm exploitability and impact with the smallest safe PoC possible.
Check for duplicates before drafting a report.

Example Triage Loop

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

## 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

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most security skills give in 713 tokens

Counted across 648 of the 828 authors here whose files we hold, read 2026-08-07

Parameterize all database queriesin 68 of 648, across 51 files
Hash passwords using bcrypt, scrypt, or argon2in 49 of 648, across 36 files
Apply rate limiting to authentication endpointsin 48 of 648, across 24 files
Configure security headersin 35 of 648, across 19 files
Validate all inputsin 32 of 648, across 24 files
Validate all external input at the system boundaryin 29 of 648, across 19 files
Run containers as a non-root userin 28 of 648, across 15 files
Use httponly secure samesite cookies for sessionsin 26 of 648, across 15 files
Run dependency audits before every releasein 21 of 648, across 10 files
Encode output to prevent cross-site scriptingin 21 of 648, across 11 files
Copy dependencies before source codein 20 of 648, across 9 files
Store secrets in environment variablesin 20 of 648, across 18 files

Said here and by no other author read

check bounty scope and exclusions first
find real network or user entrypoints
trace each code path end to end
confirm exploitability with a minimal PoC
check for duplicate reports before drafting
drop test, demo, fixture, and vendored code

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.