# Bug Bounty Field Manual

Bug bounty work is a sequence of decisions: establish permission, choose a reachable security boundary, construct a test, prove the impact, and make the finding reproducible. Tools support that sequence. A large asset list or scanner output is an input to research, not evidence that a vulnerability exists.

This manual covers the major program models and technical scope families: OSS repositories, self-hosted products, web applications, APIs, network services, mobile, desktop and extensions, cloud and containers, AI systems, smart contracts, and embedded devices. Individual programs can define unusual combinations; their exact written policy takes precedence over any generic category here.

## Choose your entry point

| Need | Open | Result to produce |
|---|---|---|
| Decide what to learn and in what order | [Roadmap](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/roadmap.html) | A realistic rotation of lab work and live research |
| Find an eligible program | [Platforms and participation](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/platforms.html) | A shortlist with permission, reward, and access checked separately |
| Interpret a repo, wildcard, app ID, chain address, or hardware scope | [Scope model](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/scope.html) | A recorded authorization decision for each asset and action |
| Start a hunt | [Operating playbook](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/operations.html) | A mapped boundary, test hypothesis, and evidence trail |
| Review code or reproduce a product bug locally | [OSS and self-hosted](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/oss.html) | A versioned, reachable, reproducible finding |
| Investigate an application or API | [Web and API](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/web-api.html) | A controlled comparison of expected and actual behavior |
| Review network services and appliances | [Network services](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/network.html) | A service-level finding with exact transport, identity and impact |
| Test device applications | [Mobile](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/mobile.html) / [Desktop and extensions](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/desktop.html) | A release-relevant crossing of an OS, process, or account boundary |
| Examine infrastructure or agent systems | [Cloud](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/cloud.html) / [AI and MCP](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/ai.html) | A demonstrated identity, tenant, resource, or tool-authority failure |
| Investigate a protocol or physical product | [Web3](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/web3.html) / [Hardware and firmware](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/hardware.html) | An invariant or trust-boundary failure in a reproducible local setup |
| Run preflight or prepare a submission | [Master checklist](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/checklist.html) | A reviewed, minimal, policy-compliant report |
| Recall commands and evidence requirements | [Cheat sheet](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/cheat-sheet.html) | The next bounded action, with prerequisites |
| Reuse working records | [Templates](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/templates.html) | Scope, hypotheses, coverage, and report records |

## Four distinct working aids

| Artifact | Question it answers | How to use it |
|---|---|---|
| Roadmap | What capability should I build next? | Follow milestone gates; extend a phase if its output is not reproducible |
| Playbook | How do I investigate this kind of target? | Follow decisions and branch on findings; do not run every tool blindly |
| Checklist | What must I verify or explicitly mark inapplicable? | Record pass, finding, blocked, untested, or not applicable with a reason |
| Cheat sheet | What syntax, evidence, or distinction do I need now? | Use alongside the relevant scope and playbook, never as independent authorization |

## A productive first session

1. Shortlist three programs through their official policy pages. Record whether each is open to you, currently accepting submissions, and paying for your chosen asset type.
2. Choose one exact asset or repository release. Save the policy reference, relevant scope text, exclusions, and the time you checked it.
3. Establish the permitted environment. Prepare your own accounts, tenants, device, local fork, or isolated product deployment as appropriate.
4. Map one valuable workflow from entry point to stored data or privileged operation. Write three specific hypotheses about its trust boundaries.
5. Test one hypothesis with a baseline and a negative control. Save enough evidence to reproduce it; end the session with the next concrete action.

This is an operating recommendation, not a claim that a first session should produce a paid finding. A disproved hypothesis with a clear reason is useful progress.

## Current changes that affect target selection

- **Huntr:** its 2026 transition changed the traditional OSS submission route. Use the dated status discussion in [Platforms](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/platforms.html), not an old list of eligible Python projects. [Huntr 2.0 FAQ](https://blog.huntr.com/huntr-2-0-faq).
- **Internet Bug Bounty:** Node.js’s official notice confirms the IBB funding pause and continuing Node.js security intake without bounties. The direct IBB policy could not be reverified on 14 September 2026; check it before planning new work. [Node.js notice](https://nodejs.org/en/blog/announcements/discontinuing-security-bug-bounties).
- **Rules are layered:** target permission, cloud-provider acceptable testing rules, platform terms, disclosure restrictions, and reward eligibility can all apply to one investigation. A program's safe harbor does not bind third parties. [HackerOne Gold Standard Safe Harbor](https://docs.hackerone.com/en/articles/8494525-gold-standard-safe-harbor-statement).

## Evidence standard

Every candidate should answer: **who can do what to which resource, across which boundary, under what preconditions, on which version?** A claim of impact should be demonstrated with synthetic data or owned resources when possible, and clearly distinguished from additional consequences inferred from the root cause.

An outdated dependency is a lead until affected code and exploit conditions are established. A prompt that changes an assistant's tone is not automatically an AI security vulnerability. A crash, exposed debug string, permissive header, or code pattern needs a relevant security consequence and eligible scope. The technical chapters give the evidence threshold for each case.

## Research basis and limits

The [14 September review](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/review.html) adds missing procedures and corrects selected technical and policy claims; it does not redate every original reference. The original policy and technical chapters were checked on **11 September 2026**; the expanded testing modules, vulnerability catalog, and ATT&CK mappings were researched on **12 September 2026**. Each chapter links claims to primary documentation and records source context; the [Sources](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/sources.html) index gathers those references. Dynamic eligibility, invitation rules, supported releases, reward ranges, and provider policies must be rechecked before a new engagement. This manual does not promise earnings or a complete inventory of every currently running program.

The uploaded **all.txt** was inspected as a local text input: **5,520 nonempty, unique hostname-like rows**. It has no policy URLs, timestamps, environment restrictions, or authorization evidence. It was not probed, resolved, scanned, or treated as an approved target list. The scope chapter shows how to turn such an inventory into a review queue. Source: uploaded all.txt; supplied local copy, no public URL.

The roadmaps, prioritization weights, operating gates, example records, and test designs are original analytical recommendations informed by the linked technical standards. They are not platform requirements unless a platform rule is explicitly cited. CLI examples were checked against documentation; they were not executed against live targets and must be matched to the installed tool version.


## Reusable reference tools

- [Reusable test modules](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/modules.html)
- [Vulnerability catalog](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/vulnerabilities.html)
- [Command workbench](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/commands.html)
- [Coverage & reuse map](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/coverage.html)
- [MITRE ATT&CK mapping](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/attack.html)
- [Review & updates](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/review.html)