security-bounty-hunter

Use this when the goal is practical vulnerability discovery for responsible disclosure or bounty submission, not a broad best-practices review. Bias toward remotely reachable, user-controlled attack paths and throw away patterns that platforms routinely reject as informative or out of scope. These are the kinds of issues that consistently matter: These are usually low-signal or out of bounty scope unless the program says otherwise: Then manually filter: Before submitting: - 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?" - 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 - 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...