Bug Bounty Reporting skill for Codex

A report succeeds when a triager who has never seen the target reproduces it in five minutes, agrees with the impact, and has nothing to ask. It fails when the bug is out of scope, the proof touched other users’ data, or the impact claim outruns the evidence.

Gate: is this reportable?

Before writing anything, confirm with the user and the program page (read it, do not assume):

• The program exists and the user is eligible (public program, or a private invite).
• The exact asset is listed in scope; the vulnerability class is not in the out-of-scope list (common exclusions: self-XSS, clickjacking on non-sensitive pages, missing headers without impact, rate limiting, SPF/DMARC, version disclosure).
• The testing that produced it followed the rules: test accounts only, no automated scanning if banned, no social engineering, no DoS, no access to other users’ data beyond the minimum needed to prove the issue.
• The program’s safe harbor statement covers the activity.

If the user tested something not in scope or broke a rule, say so plainly. Do not help frame out-of-scope testing as authorized. Recommend they stop, avoid further access, and (where the program allows) disclose honestly what happened.

Never help exfiltrate, retain or publish data obtained through the bug. If real user data was accessed, the report says what was seen, that it was not kept, and nothing more.

Build the proof of concept

• Minimal: the fewest requests that show the flaw. Strip unrelated headers, cookies and parameters from captured requests (keep what is needed to reproduce).
• Safe: use two of your own accounts for access-control bugs (attacker and victim). For stored XSS use alert(document.domain) or a console log, never a payload that steals cookies or beacons to your server. For SSRF, prove reach to an endpoint you control or a harmless internal response, never cloud credentials beyond the first line of proof.
• Deterministic: run it again from a clean session before submitting. Note timing and preconditions (feature flag, region, account tier).
• Redacted: replace tokens and session cookies with <redacted> in the report text; the triager will use their own.

Severity

Use the program’s taxonomy: HackerOne programs usually use CVSS (3.1 or 4.0 per program); Bugcrowd uses its Vulnerability Rating Taxonomy (P1-P5); Intigriti uses CVSS-based severity. State your suggested severity, the vector if CVSS, and one sentence of reasoning tied to evidence. Triagers lower inflated ratings and remember the reporter who inflated them.

Claim	Evidence the report must contain
Account takeover	Step-by-step takeover of your second test account, without its credentials
Access to other users’ data	Request from account A returning account B’s object (both yours)
RCE	Command output proving execution (id, hostname), then stop
Stored XSS impact on admins	Where the payload renders and which role sees it; harmless payload only
SSRF to internal network	Response or timing that proves internal reach; no credential harvesting

Theoretical chains (“an attacker could then…”) without a demonstrated step are listed as possible impact, not as the severity basis.

Report template

## Summary
IDOR in `GET /api/v1/orders/{id}` on shop.example.com lets any logged-in user read other
customers' orders (name, address, items).

## Severity
High, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N (6.5); C:H because full shipping
addresses of any customer are returned. Order IDs are sequential, so enumeration is trivial.

## Steps to reproduce
1. Create account A ([email protected]) and account B ([email protected]).
2. As B, place an order; note the order ID in the confirmation URL (e.g. 884213).
3. As A, send:
   GET /api/v1/orders/884213 HTTP/2
   Host: shop.example.com
   Authorization: Bearer <A's token, redacted>
4. Response is 200 with B's order (screenshot 2, redacted).

## Impact
Any registered user (free sign-up) can read any order. I accessed only my own two test
accounts' orders and did not enumerate IDs.

## Suggested fix
Check that the order's customer ID matches the session's customer before returning it.

## Environment
Chrome 141, Burp Suite Community 2025.x, tested 2026-10-21 14:05 UTC from one IP.

Title formula: <Vuln class> in <component> allows <actor> to <impact>. Example: “Stored XSS in support ticket subject allows customers to run script in agent dashboard”.

Before submitting

• Search the program’s disclosed reports and changelog for the same issue; duplicates are closed against the first report.
• One vulnerability per report unless the program asks for chains together. Same root cause across endpoints goes into one report with all locations listed.
• Attach a short video only when steps are UI-heavy; text steps must still work alone.
• Read the draft as the triager: every claim has a step or screenshot behind it.
• Submission is the user’s action. Show them the final text and let them submit it; do not post to the platform on their behalf without explicit confirmation.

After submitting

• Answer triager questions with new evidence, not repetition. Keep tone neutral; the triager is not the developer.
• Do not retest after the fix is reported deployed unless the program invites it, and never test variants on production without staying inside the rules.
• Disclosure (blog posts, talks) only per the program’s disclosure policy and after the program agrees. Redact customer details even when public disclosure is approved.
• If severity is downgraded and you disagree, ask once, with a specific piece of evidence or a policy reference; mediation through the platform is the escalation path.

Common rejection causes

• Out-of-scope asset (a third-party SaaS, a subdomain not listed, a staging host).
• “Missing best practice” reports with no demonstrated exploit.
• Self-XSS, logout CSRF, or CORS misconfiguration without credentialed data readout.
• Proof relying on a compromised victim device or an attacker already holding the session.
• Scanner output pasted without manual confirmation.