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