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 toolingshell=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
Source: affaan-m/ECC → skills/security-bounty-hunter/SKILL.md
1---2name: security-bounty-hunter-23description: 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.4---5# Security Bounty Hunter
6
7Use this when the goal is practical vulnerability discovery for responsible disclosure or bounty submission, not a broad best-practices review.
8
9## When to Use
10
11- Scanning a repository for exploitable vulnerabilities
12- Preparing a Huntr, HackerOne, or similar bounty submission
13- Triage where the question is "does this actually pay?" rather than "is this theoretically unsafe?"
14
15## How It Works
16
17Bias toward remotely reachable, user-controlled attack paths and throw away patterns that platforms routinely reject as informative or out of scope.
18
19## In-Scope Patterns
20
21These are the kinds of issues that consistently matter:
22
23| Pattern | CWE | Typical impact |
24| --- | --- | --- |
25| SSRF through user-controlled URLs | CWE-918 | internal network access, cloud metadata theft |
26| Auth bypass in middleware or API guards | CWE-287 | unauthorized account or data access |
27| Remote deserialization or upload-to-RCE paths | CWE-502 | code execution |
28| SQL injection in reachable endpoints | CWE-89 | data exfiltration, auth bypass, data destruction |
29| Command injection in request handlers | CWE-78 | code execution |
30| Path traversal in file-serving paths | CWE-22 | arbitrary file read or write |
31| Auto-triggered XSS | CWE-79 | session theft, admin compromise |
32
33## Skip These
34
35These are usually low-signal or out of bounty scope unless the program says otherwise:
36
37- Local-only `pickle.loads`, `torch.load`, or equivalent with no remote path
38- `eval()` or `exec()` in CLI-only tooling
39- `shell=True` on fully hardcoded commands
40- Missing security headers by themselves
41- Generic rate-limiting complaints without exploit impact
42- Self-XSS requiring the victim to paste code manually
43- CI/CD injection that is not part of the target program scope
44- Demo, example, or test-only code
45
46## Workflow
47
481. Check scope first: program rules, SECURITY.md, disclosure channel, and exclusions.
492. Find real entrypoints: HTTP handlers, uploads, background jobs, webhooks, parsers, and integration endpoints.
503. Run static tooling where it helps, but treat it as triage input only.
514. Read the real code path end to end.
525. Prove user control reaches a meaningful sink.
536. Confirm exploitability and impact with the smallest safe PoC possible.
547. Check for duplicates before drafting a report.
55
56## Example Triage Loop
57
58```bash
59semgrep --config=auto --severity=ERROR --severity=WARNING --json
60```
61
62Then manually filter:
63
64- drop tests, demos, fixtures, vendored code
65- drop local-only or non-reachable paths
66- keep only findings with a clear network or user-controlled route
67
68## Report Structure
69
70```markdown
71## Description
72[What the vulnerability is and why it matters]
73
74## Vulnerable Code
75[File path, line range, and a small snippet]
76
77## Proof of Concept
78[Minimal working request or script]
79
80## Impact
81[What the attacker can achieve]
82
83## Affected Version
84[Version, commit, or deployment target tested]
85```
86
87## Quality Gate
88
89Before submitting:
90
91- The code path is reachable from a real user or network boundary
92- The input is genuinely user-controlled
93- The sink is meaningful and exploitable
94- The PoC works
95- The issue is not already covered by an advisory, CVE, or open ticket
96- The target is actually in scope for the bounty program
97
98---
99
100**Source:** [`affaan-m/ECC`](https://github.com/affaan-m/ECC) → `skills/security-bounty-hunter/SKILL.md`
thedixitjain