/skill

Security Bounty Hunter

Find security flaws that can lead to a valid bounty report. Do not run a broad best-practice review.

Only test code and systems you have clear permission to test. Use safe proof steps. Do not harm users, delete data, or access private data.

Main Goal

Find a full attack path:

1. An attacker can reach the entry point.
2. The attacker can control the input.
3. The input reaches a risky action.
4. The app does not stop or clean the input.
5. The flaw causes clear harm.

Do not report a risky code line unless you can prove this path.

High-Value Patterns

Also check for chains. Two small bugs may join into one serious flaw.

Low-Value Findings to Skip

Skip these unless the bounty rules say they are in scope:

• Local-only use of pickle.loads, torch.load, or similar code
• eval() or exec() in a command-line tool with no remote input
• shell=True with a fixed command and no user-set part
• Missing security headers with no clear attack
• Rate-limit claims with no clear harm or repeatable proof
• Self-XSS that needs the victim to paste or run code
• CI or build attacks outside the bounty scope
• Code used only in tests, demos, examples, or fixtures
• Dead code or features that are off in real builds
• Debug mode that only works after local setup
• Dependency version warnings with no proof the app is exposed
• Secrets that are fake, old, revoked, or only used in tests
• Denial of service that needs huge cost, local access, or unsafe testing

Do not ignore a test or demo file if the real app ships or runs it.

Workflow

1. Read the bounty rules, SECURITY.md, scope list, and report steps.
2. Note banned tests, safe-harbor terms, and rate limits.
3. Find real entry points such as web routes, APIs, uploads, webhooks, parsers, sockets, and jobs started by remote input.
4. Track user input from the entry point to the risky action.
5. Check each guard, clean-up step, type check, allowlist, and access check.
6. Check the real build settings. A flaw may depend on a flag, role, or version.
7. Use a small and safe proof of concept.
8. Test only with data and accounts you own.
9. Stop if a test may harm users, change real data, or cause a service outage.
10. Check open issues, past reports, advisories, and CVEs for copies.
11. Write the report only when reach, control, harm, and scope are clear.

Static tools may help find leads. Their output is not proof.

semgrep --config=auto --severity=ERROR --severity=WARNING --json

Remove results from tests, demos, fixtures, copied code, and dead paths. Keep only results with a clear route from remote input to real harm.

Edge Cases

• If login is needed, state the lowest role needed.
• If admin action is needed, explain why an attacker can cause it.
• If a job runs later, prove remote input starts or shapes that job.
• If a proxy or gateway blocks the attack, test the normal setup too.
• If the flaw only works with rare settings, list those settings.
• For SSRF, check redirects, DNS changes, URL parsing, IPv6, and private IP forms.
• For file paths, check encoded paths, mixed path marks, links, and archive files.
• For uploads, check both file checks and what later opens the file.
• For XSS, state who must view the page and whether normal use will trigger it.
• For race bugs, use the smallest safe test and show that results repeat.
• For third-party code, prove the project uses the weak path in a shipped version.
• If you cannot test safely, give code proof and label the missing proof. Do not claim full impact.

Concrete Example

A route accepts a URL and asks the server to fetch it:

@app.post("/preview")
def preview():
    url = request.json["url"]
    return requests.get(url).text

Check the full path:

1. Confirm /preview is on in the normal app.
2. Find out if a guest or basic user can call it.
3. Confirm url comes from the request.
4. Check for URL rules, redirect checks, DNS checks, and network blocks.
5. Use a server you own to prove the app makes the request.
6. Do not request cloud data or private services without clear permission.
7. Report SSRF only if the server can reach a target that creates real harm.

A safe proof request may look like this:

curl -X POST https://target.example/preview \
  -H 'Content-Type: application/json' \
  -d '{"url":"https://server-you-own.example/proof"}'

Save the request time and the matching log from your own server.

Report Format

## Summary
[One short line that names the flaw and the harm.]

## Scope
[Why this target and feature are in scope.]

## Attack Path
[Who can attack, what input they control, and where it goes.]

## Weak Code
[File path, line numbers, and a small code part.]

## Proof of Concept
[Small, safe steps that another person can repeat.]

## Result
[What happened. Include safe logs or output.]

## Impact
[What the attacker can read, change, or run.]

## Needed Conditions
[Role, settings, user action, network access, or timing.]

## Affected Versions
[Tested version, commit, build, or live target.]

## Fix Idea
[A short fix, if it is clear.]

Remove tokens, cookies, private data, and secrets from all proof files.

Final Check

Before filing a report, confirm:

• The target and feature are in scope.
• The attack starts at a real user or network edge.
• The attacker controls the key input.
• The input reaches the risky action.
• Normal guards do not stop the attack.
• The proof works more than once when safe to repeat.
• The harm is clear and not just a guess.
• The issue is not already public or reported.
• The proof does not expose secrets or private user data.
• Every claim says what was tested and what was only inferred.

If any key point is missing, keep the item as a lead. Do not call it a confirmed flaw.