--- name: report-writing description: Bug bounty report writing for H1/Bugcrowd/Intigriti/Immunefi category: security risk: safe source: https://github.com/elementalsouls/Claude-BugHunter source_repo: elementalsouls/Claude-BugHunter source_type: community date_added: '2026-09-20' license: MIT license_source: https://github.com/elementalsouls/Claude-BugHunter/blob/main/LICENSE compatibility: Process guidance; no tooling required. Docs-only; upstream templates not bundled. sources: community, operator_experience --- # REPORT WRITING Impact-first. Human tone. No theoretical language. Triagers are people. --- ## THE MOST IMPORTANT RULE > **Distinguish demonstrated behavior from untested hypotheses and state uncertainty precisely.** > Do not present untested impact as observed. A bounded, labeled hypothesis or suspected vulnerability can still be reported when the program permits it; do not exceed scope to manufacture proof. ``` BAD: "This vulnerability could potentially allow an attacker to access user data." GOOD: "An attacker can access any user's order history by changing the user_id parameter to the target user's ID. I confirmed this using two test accounts: attacker@test.com (ID 123) successfully retrieved victim@test.com (ID 456) orders, including their shipping address and payment method last 4 digits." ``` --- ## TITLE FORMULA ``` [Bug Class] in [Exact Endpoint/Feature] allows [attacker role] to [impact] [victim scope] ``` **Good titles (specific, impact-first):** ``` IDOR in /api/v2/invoices/{id} allows authenticated user to read any customer's invoice data Missing auth on POST /api/admin/users allows unauthenticated attacker to create admin accounts Stored XSS in profile bio field executes in admin panel — allows privilege escalation SSRF via image import URL parameter reaches AWS EC2 metadata service Race condition in coupon redemption allows same code to be used unlimited times ``` **Bad titles (vague, useless to triager):** ``` IDOR vulnerability found Broken access control XSS in user input Security issue in API Unauthorized access to user data ``` --- ## HACKERONE REPORT TEMPLATE ```markdown ## Summary [One paragraph: what the bug is, where it is, what an attacker can do. Be specific. Include: endpoint, method, parameter, data exposed, required access level.] Example: "The `/api/users/{user_id}/orders` endpoint does not verify that the authenticated user owns the requested user_id. An attacker can enumerate any user's order history, including PII (email, address, phone) and purchase history, by incrementing the user_id parameter. No privileges beyond a standard free account are required." ## Vulnerability Details **Vulnerability Type:** IDOR / Broken Object Level Authorization **CVSS 3.1 Score:** 6.5 (Medium) — AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N **Affected Endpoint:** GET /api/users/{user_id}/orders ## Steps to Reproduce **Environment:** - Attacker account: attacker@test.com, user_id = 123 - Victim account: victim@test.com, user_id = 456 - Target: https://target.com **Steps:** 1. Log in as attacker@test.com, obtain Bearer token 2. Send the following request: ``` GET /api/users/456/orders HTTP/1.1 Host: target.com Authorization: Bearer ATTACKER_TOKEN_HERE ``` 3. Observe response: ```json { "orders": [ {"id": 789, "items": [...], "email": "victim@test.com", "address": "123 Main St..."} ] } ``` The response contains victim's full order history and PII despite being requested by a different user. ## Impact An authenticated attacker can enumerate all user orders by iterating user_id values. This exposes: full name, email, shipping address, purchase history, and payment method (last 4). With ~100K users, this represents a mass PII breach affecting all registered users. Exploitation requires only a free account and takes minutes with a simple loop. ## Recommended Fix Add server-side ownership verification: ```python if order.user_id != current_user.id: raise Forbidden() ``` ## Supporting Materials [Screenshot showing attacker's session returning victim's order data] [Video walkthrough if available] ``` --- ## BUGCROWD REPORT TEMPLATE ```markdown # [IDOR] User order history accessible without authorization via /api/users/{id}/orders **VRT Category:** Broken Access Control > IDOR > P2 ## Description [Same impact-first paragraph as HackerOne summary] ## Steps to Reproduce [Same structured steps — exact HTTP requests, exact responses] ## Proof of Concept [Screenshot/video showing the actual impact] ## Expected vs Actual Behavior **Expected:** 403 Forbidden when user_id does not match authenticated user **Actual:** 200 OK with victim's full order data ## Severity Justification P2 (High) — Direct read access to other users' PII. Affects all user accounts. No user interaction required. Exploitable by any authenticated user. Automated enumeration could exfil all [N] user records in minutes. ## Remediation Add ownership verification: `if order.user_id != current_user.id: raise 403` ``` --- ## INTIGRITI REPORT TEMPLATE ```markdown # [Bug Class]: [Exact Impact] in [Endpoint/Feature] ## Description [Impact-first paragraph. Start with what an attacker can do, not with how you found it. Include: endpoint, method, parameter, data exposed, required privileges.] ## Steps to Reproduce **Environment:** - Attacker: email=attacker@test.com (standard account, no special role) - Victim: email=victim@test.com - Tested: [date] **Reproduction steps:** 1. [Login as attacker / visit URL / send request] 2. Send the following HTTP request: \```http METHOD /endpoint HTTP/1.1 Host: target.com Authorization: Bearer ATTACKER_TOKEN Content-Type: application/json {"param": "victim_id_here"} \``` 3. Observe response contains victim's private data: \```json {"email": "victim@test.com", "address": "123 Main St", ...} \``` ## Impact [Specific, quantified impact. What data, how many users, what can attacker do.] CVSS 3.1 Score: X.X ([Severity]) — AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N ## Remediation [1-3 sentence concrete fix. Include code if helpful.] ## Attachments [Screenshot or Loom video showing the impact — Intigriti triagers prefer video for complex bugs] ``` **Intigriti-specific notes:** - Title format: `[Bug Class]: [One-line impact]` (no formula required, but keep it specific) - Severity is set by you: Critical/High/Medium/Low/Exceptional - CVSS 3.1 is standard (CVSS 4.0 also accepted on newer programs) - PoC video is valued much more than screenshot alone — record with Loom - Safe harbor and testing limits are program-specific; read the exact terms and never infer permission for more aggressive tests --- ## IMMUNEFI REPORT TEMPLATE ```markdown # [Bug Class] — [Protocol Name] — [Severity] ## Summary [One paragraph with: root cause, affected function, economic impact, attack cost. Include numbers where possible: "attacker can drain $X in Y transactions."] ## Vulnerability Details **Contract:** `VulnerableContract.sol` **Function:** `claimRedemption()` **Bug Class:** Accounting State Desynchronization **Severity:** Critical ### Root Cause [Exact code snippet showing the vulnerable code with comments] ## Proof of Concept ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; // Foundry PoC — run: forge test --match-test test_exploit -vvvv contract ExploitTest is Test { // ... full working exploit } ``` ## Impact [Quantified: "Attacker can drain X% of TVL = $Y at current rates. Requires $Z gas. Attack is repeatable."] ## Recommended Fix [Specific code change with before/after] ``` --- ## CVSS 3.1 QUICK SCORING ### Formula ``` CVSS = f(AV, AC, PR, UI, S, C, I, A) ``` ### Calculate from the actual scenario Use the official FIRST calculator for the version required by the program. CVSS metrics are not additive points, and a vulnerability class has no fixed score. Record the complete vector and evidence for each metric, including the correct privilege weight under the chosen Scope in v3.1. Program priority/bounty categories are separate from CVSS. --- ## SEVERITY DECISION GUIDE ### Critical (P1) - Full account takeover of any user without interaction - Remote code execution - SQLi with ability to dump/modify entire DB - Auth bypass to admin panel - SSRF to cloud metadata → IAM credentials exfil ### High (P2) - Mass PII exposure (email, phone, SSN, payment data) - Privilege escalation from user to admin - SSRF reaching internal services (data returned) - Stored XSS executing for all users of sensitive feature - Payment bypass / financial loss without limit ### Medium (P3) - IDOR on specific user's non-critical data - XSS on low-sensitivity page requiring victim interaction - CSRF on important but non-critical action - Rate limit bypass on OTP (with effort demonstrated) ### Low (P4) - Information disclosure (non-sensitive, no PII) - Clickjacking on sensitive action WITH working PoC - CORS on limited data --- ## SEVERITY SELF-ASSESSMENT These are evidence questions, not an additive severity formula: ``` 1. Exposes PII / health / financial data of other users? → assess the applicable confidentiality/integrity/availability impact 2. Allows account takeover or privilege escalation? → assess the demonstrated privilege/impact boundary 3. Requires ZERO user interaction from victim? → assess the applicable confidentiality/integrity/availability impact 4. Affects ALL users (not specific condition)? → assess the applicable confidentiality/integrity/availability impact 5. Remotely exploitable with no internal network access? → choose the correct vector metric, without a preset severity ``` --- ## DOWNGRADE COUNTERS | Program Says | Counter With | |---|---| | "Requires authentication" | "Attacker needs only a free account — no special role or permission" | | "Limited impact" | "Affects [N] users / exposes [PII type] / $[amount] at risk" | | "Already known" | "Show me the report number — I searched hacktivity and found none" | | "By design" | "Show me the documentation stating this is intended behavior" | | "Low CVSS" | "CVSS doesn't capture business impact — attacker can extract [X] in [Y] minutes" | | "Not exploitable" | "Here is the exact response showing victim's data returned to attacker session" | --- ## THE 60-SECOND PRE-SUBMIT CHECKLIST ``` [ ] Title follows formula: [Class] in [endpoint] allows [actor] to [impact] [ ] First sentence states exact impact in plain English [ ] Steps to Reproduce has exact HTTP request (copy-paste ready) [ ] Response showing the bug is included (screenshot or JSON body) [ ] Two test accounts used — not just one account testing itself [ ] CVSS score calculated and included [ ] Recommended fix is 1-2 sentences (not a lecture) [ ] No typos in endpoint paths or parameter names [ ] Report is < 600 words — triagers skim long reports [ ] Severity claimed matches impact described — don't overclaim [ ] Observed facts and untested hypotheses are clearly separated [ ] PoC is reproducible by triager from a fresh state ``` --- ## Contents - [CVSS 4.0 QUICK REFERENCE (newer programs)](references/details.md) - [HUMAN TONE GUIDELINES](references/details.md) - [STEPS TO REPRODUCE FORMAT (triager-optimized)](references/details.md) - [Related Skills & Chains](references/details.md) - [Operator Notes (Claude-BugHunter)](references/details.md) ## When to Use - You need this skill's process guidance (reporting format, evidence handling, detection notes, or scope triage) during an authorized engagement. - No active probing is involved in this step. ## Limitations - Process guidance only; it does not authorize probing or exploitation — those steps need their own authorized skill and confirmation gate. - Docs-only import: upstream templates, commands, and research assets are not bundled. ### Example ```markdown Apply this skill's checklist to the current engagement notes and report gaps. ``` > Adapted from [elementalsouls/Claude-BugHunter](https://github.com/elementalsouls/Claude-BugHunter) (MIT); frontmatter, When to Use/Limitations, and safety boundaries added for upstream compliance. Docs-only import: executable helpers, commands, engine, and research assets not bundled. ## Evidence, disclosure and template limits All accounts, counts, financial values, scenarios and reported impacts in templates are illustrative placeholders, not verified findings or evidence of a real engagement. Two test accounts support a cross-account proof, not a claim that all users or 100K records are affected. Do not enumerate or exfiltrate additional records to quantify impact; use owner-provided scope and a minimal approved proof. Mark unknown reach, causality, exploitability and policy explicitly rather than replacing uncertainty with confident language. Report suspected security issues through the authorized disclosure channel even if further proof would be unsafe or prohibited; missing optional sibling skills must not block responsible reporting. Sanitize secrets/PII, retain necessary reproducibility privately, and obtain explicit authorization before submitting a report, replying to triagers or uploading screenshots/videos to external services. A duplicate need not have a publicly visible report; request clarification respectfully without asserting nondisclosure proves novelty. CVSS/VRT/platform templates and word limits are examples requiring current program confirmation, not universal law or payout guarantees.