Hackerone

HackerOne Bounty Scope-Guard Skill

You are executing a HackerOne bug bounty workflow. This Skill is a scope-guard wrapper: first parse and enforce the program scope and program rules, then hand each in-scope asset to pentest-flow for the actual security testing. Never touch an out-of-scope asset at any stage.

The launch argument is a HackerOne program link (<SCOPE LINK>), for example hackerone.com/<handle> or .../policy_scopes. This Skill has no preset scan target (requires_target: false in frontmatter); targets are discovered from the program scope.

Startup and output contract

• Do not load or print the reference document during startup. It contains report-template material and examples; load it only when preparing a report or when parsing an ambiguous scope requires it.
• Resolve the supplied program link or obtain a pasted scope before claiming that scope is defined. Never treat example assets in this Skill or its references as observed program scope.
• Once scope is confirmed, keep the status concise: Scope defined: <count> in-scope, <count> out-of-scope. Starting recon on <asset>.
• Automatically begin recon on the first confirmed URL or WILDCARD asset after you have printed that status in the same workflow that loaded scope. Do not pause for an asset-selection question unless scope is ambiguous, contains no directly supported assets, or the user explicitly asks to choose.
• Mid-session user check-ins (e.g. "ready to begin?", "are we ready?") are not a green light by themselves: answer with scope summary, intended first asset, and any blockers first. Start or resume recon tools only after an explicit go-ahead or a clear recon/pentest command.
• Do not print raw HTML, full reference text, or raw tool output. If scope cannot be loaded, ask the user to paste the Scope tab and stop before testing.
• Never treat hackerone.com as the recon/pentest target. The program link is only a discovery seed. Do not run js_recon, dir_enum, subdomain_enum, or attack tooling against HackerOne itself.

Phase 1: Read scope

1. Call hackerone_scope first (required)

   • Immediately call: hackerone_scope(program="<SCOPE LINK or handle>").
   • This tool queries HackerOne public GraphQL and returns structured in-scope and out-of-scope assets. Use it even if a prior HTML fetch showed an empty SPA shell.
   • Do not reverse-engineer HackerOne JavaScript bundles, dump /assets/static/*, or run js_recon on hackerone.com/* to discover the GraphQL endpoint.

2. Fallback only if hackerone_scope fails

   • Optional one-shot GET of the program page is allowed only as diagnostics; an empty SPA shell is normal and not a scope source.

   • Ask the user to paste the in-scope and out-of-scope tables from the program page Scope tab. Provide this example format:

     In scope:
     https://api.example.com        | URL       | Eligible for bounty
     *.example.com                  | WILDCARD  | Eligible for bounty
     app.example.com                | URL       | In scope, NOT bounty-eligible
     com.example.android            | GOOGLE_PLAY_APP_ID | Eligible for bounty
     
     Out of scope:
     blog.example.com               | URL
     *.corp.example.com             | WILDCARD
     

3. Parse leniently

   • Extract two lists from the tool result or paste: in-scope and out-of-scope.
   • Recognize asset types by human label or API enum: URL, WILDCARD (*.x.com), CIDR/IP, SOURCE_CODE, GOOGLE_PLAY_APP_ID/APPLE_STORE_APP_ID/TESTFLIGHT/OTHER_APK/OTHER_IPA, HARDWARE, AI_MODEL, SMART_CONTRACT, OTHER, and similar values.
   • Recognize three eligibility states. Submission eligibility and bounty eligibility are independent booleans:
     • submission=true, bounty=true → in scope, testable, bounty eligible.
     • submission=true, bounty=false → in scope, testable, not bounty eligible. Do not confuse this with out of scope.
     • submission=false → out of scope; never test it.
   • If parsing is uncertain, ask the user to confirm. Never default an uncertain asset to in-scope.

4. Record the boundary internally

   • Keep the in-scope assets with their type and eligibility available to the workflow.
   • Keep an out-of-scope deny-list for enforcement throughout the run.

Phase 2: Enforce boundaries

Before any testing begins, state and follow these hard rules throughout:

1. Scope boundary

   • Test only assets in the in-scope list.
   • Never touch an asset on the out-of-scope deny-list: do not fetch it, scan it, or send any payload to it.
   • pentest-flow may directly handle only URL and WILDCARD assets. Other types (mobile apps, source code, CIDR, hardware, and so on) are not automated; ask the user to confirm how they should be handled.

2. Program rules (in addition to VulnClaw's existing BLOCKED_PATTERNS and RESERVED_IP_RANGES)

   • No DoS or availability impact: prohibit stress tests, resource exhaustion, and high-volume concurrency.
   • Respect rate and automation limits: operate slowly and serially, and follow any program rule that prohibits automated scanning.
   • No social engineering: do not target or phish people.
   • Minimal impact and no PII exfiltration: stop once a vulnerability is verified; do not export real user data or perform destructive actions.

3. Handle exceptions safely

   • If any step could cross the scope boundary or violate a program rule, stop and ask the user.

Phase 3: Enumerate and confirm

1. Use the concise startup status from the output contract and select the first directly supported asset automatically.
2. Ask which asset to start with only when the output contract requires it.
3. Handle one asset at a time and confirm each one separately. Avoid concurrency that could cross the scope boundary or trigger rate limits.

Phase 4: Delegate to pentest-flow

For the selected single in-scope asset:

1. Treat that asset as the active target. Run the full recon → vulnerability-discovery → exploitation workflow against it, not against the HackerOne scope link.
2. Stay within scope throughout. Exclude and report any newly discovered subdomain or endpoint that is outside the in-scope definition, especially one that does not match an in-scope WILDCARD.
3. Continue to enforce all Phase 2 program rules.

Phase 5: Report in HackerOne format

For every confirmed finding, produce a report in HackerOne submission format:

1. Title — concise description of the vulnerability, including its type and affected asset.
2. Asset — the affected in-scope asset (URL or identifier).
3. Severity (CVSS) — CVSS vector and score (Critical/High/Medium/Low).
4. Steps to Reproduce — reproducible steps, including requests, responses, and payloads.
5. Impact — exploitability and business impact.
6. Remediation — recommended fix.

When there are multiple findings, keep each one in a separate section. Include a parameterized Python PoC using requests when useful. Remind the user that reports are for manual submission on HackerOne; this Skill never submits reports automatically.

References

• references/hackerone-report-and-scope.md — scope parsing reference (asset type ↔ API enum, three-state eligibility, pasted table shapes), mandatory program rules, and the HackerOne report template.