Security Bounty Hunter

Security Bounty Hunter

Constraints

• Apply @rules/security/backend.md and @rules/security/frontend.md
• If the project uses Laravel, also apply @rules/laravel/laravel.mdc
• Stack assumed: Laravel 11 / PHP 8.3, Filament, Livewire, Alpine.js, Blade, MySQL, Redis
• Read-only investigation — never modify, stage, commit, or push code; output is the finding report only
• Never run an exploit against infrastructure you are not authorized to test; keep PoCs minimal and safe
• Hard limits: this file stays <= 500 lines and <= 5000 tokens

Purpose

Find unknown, exploitable bugs reachable from a real network or user boundary, and write them up to a standard a bounty program will accept. Bias toward "does this actually pay?" over "is this theoretically unsafe?".

How this differs from neighbors:

• @skills/security-review/SKILL.md reviews a diff against best practices; this skill hunts unknown exploitable bugs across the whole reachable surface.
• @skills/security-threat-analysis/SKILL.md remediates a known advisory/CVE; this skill discovers the unknown one.

Use when

• Sweeping a repository for exploitable vulnerabilities
• Preparing a Huntr / HackerOne / program submission
• Triage where the question is "is this reportable?" not "is this tidy?"

In-Scope Patterns (mapped to PHP/Laravel sinks)

Skip These

Usually low-signal or out of scope unless the program says otherwise:

• Local-only unserialize/eval/exec with no remote path (CLI tooling, artisan-only)
• Fully hardcoded shell commands with no user input
• Missing security headers on their own
• Generic rate-limiting complaints with no exploit impact
• Self-XSS requiring the victim to paste content manually
• CSRF where Laravel's default protection is intact and the route is in the web group
• Findings only in demo, example, seeder, test, or vendored code

Workflow

1. Scope first — read program rules, SECURITY.md, disclosure channel, and exclusions. Confirm the target and version are in scope.
2. Map entrypoints — routes (routes/*.php, php artisan route:list), controllers, FormRequests, Livewire/Filament actions, queued jobs, webhooks, console commands reachable via HTTP, and API resources.
3. Static triage (optional) — run static triage with semgrep, larastan/phpstan, or psalm where available; treat every hit as a lead, not a finding.
4. Trace the path end to end — from the boundary input to the sink. Prove the input is genuinely user-controlled.
5. Confirm the sink is meaningful — interpolation reaches the query/command/URL/file path with no escaping or authorization between.
6. Prove exploitability — build the smallest safe PoC (a single request or short script) that demonstrates impact.
7. Check duplicates — search existing advisories, CVEs, open issues, and prior reports before drafting.

Triage loop example

# optional — any one of these, treat output as leads only
larastan analyse --no-progress
# or: vendor/bin/phpstan analyse
# or: semgrep --config=auto --severity=ERROR --json

Then manually filter: drop tests/demos/fixtures/vendored code and any non-reachable path; keep only findings with a clear network or user-controlled route to a meaningful sink.

Quick grep starters

grep -rnE "whereRaw|orderByRaw|havingRaw|DB::(raw|statement|select)\(" app/
grep -rnE "Http::(get|post)\(|file_get_contents\(|exec\(|shell_exec\(|proc_open\(" app/
grep -rnE "\{!!|unserialize\(|x-html" app/ resources/
grep -rnE "guarded\s*=\s*\[\s*\]|->all\(\)" app/

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, all the way to the sink
• The sink is meaningful and exploitable (not theoretical)
• The PoC works and is the smallest safe demonstration possible
• The issue is not already covered by an advisory, CVE, or open ticket
• The target and version are actually in scope for the program

Done when

• Each finding follows the Report Structure and passes every Quality Gate item
• Out-of-scope and low-signal patterns were filtered out, not reported
• No code was modified and no unauthorized exploit was run

Related Skills

• @skills/security-review/SKILL.md — best-practices review of a known change set
• @skills/security-threat-analysis/SKILL.md — remediate a referenced advisory/CVE