Report Writing

# REPORT WRITING

Impact-first. Human tone. No theoretical language. Triagers are people.

> Never use "could potentially" or "could be used to" or "may allow". > Either it does the thing or it doesn't. If you haven't proved it, don't claim it.

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."

[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

```markdown

[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 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

Environment:

• Attacker account: attacker@test.com, user_id = 123
• Victim account: victim@test.com, user_id = 456
• Target: https://target.com

• Log in as attacker@test.com, obtain Bearer token

• Send the following request:

GET /api/users/456/orders HTTP/1.1
Host: target.com
Authorization: Bearer ATTACKER_TOKEN_HERE

• Observe response:

{
  "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.

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.

Add server-side ownership verification:

if order.user_id != current_user.id:     raise Forbidden()

[Screenshot showing attacker's session returning victim's order data] [Video walkthrough if available] ```

```markdown # [IDOR] User order history accessible without authorization via /api/users/{id}/orders

VRT Category: Broken Access Control > IDOR > P2

[Same impact-first paragraph as HackerOne summary]

[Same structured steps — exact HTTP requests, exact responses]

[Screenshot/video showing the actual impact]

Expected: 403 Forbidden when user_id does not match authenticated user Actual: 200 OK with victim's full order data

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.

Add ownership verification: if order.user_id != current_user.id: raise 403 ```

```markdown # [Bug Class]: [Exact Impact] in [Endpoint/Feature]

[Impact-first paragraph. Start with what an attacker can do, not with how you found it. Include: endpoint, method, parameter, data exposed, required privileges.]

Environment:

• Attacker: email=attacker@test.com (standard account, no special role)
• Victim: email=victim@test.com
• Tested: [date]

• [Login as attacker / visit URL / send request]

• Send the following HTTP request:

METHOD /endpoint HTTP/1.1
Host: target.com
Authorization: Bearer ATTACKER_TOKEN
Content-Type: application/json
{"param": "victim_id_here"} \

• Observe response contains victim's private data:

{"email": "victim@test.com", "address": "123 Main St", ...}
\

[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

[1-3 sentence concrete fix. Include code if helpful.]

[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: Intigriti enforces it, be comfortable going slightly aggressive with testing

```markdown # [Bug Class] — [Protocol Name] — [Severity]

[One paragraph with: root cause, affected function, economic impact, attack cost. Include numbers where possible: "attacker can drain $X in Y transactions."]

Contract: VulnerableContract.sol Function: claimRedemption() Bug Class: Accounting State Desynchronization Severity: Critical

Root Cause

[Exact code snippet showing the vulnerable code with comments]

[Quantified: "Attacker can drain X% of TVL = $Y at current rates. Requires $Z gas. Attack is repeatable."]

[Specific code change with before/after] ```

Formula

CVSS = f(AV, AC, PR, UI, S, C, I, A)

Metric Quick Picks

Typical Scores by Bug Class

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

Each YES raises severity:

1. Exposes PII / health / financial data of other users?        → +1 severity 2. Allows account takeover or privilege escalation?             → +2 severity 3. Requires ZERO user interaction from victim?                  → +1 severity 4. Affects ALL users (not specific condition)?                  → +1 severity 5. Remotely exploitable with no internal network access?        → baseline for High+

CVSS 4.0 replaced CVSS 3.1 in November 2023. Some newer programs require it.

Key Differences from CVSS 3.1

CVSS 4.0 Score Examples

Quick CVSS 4.0 Calculator

Use: https://www.first.org/cvss/calculator/4.0
Key fields:
  VC/VI/VA = Vulnerable System Confidentiality/Integrity/Availability
  SC/SI/SA = Subsequent System (downstream impact)
  AT = None (no special condition) | Present (race/specific config needed)
  UI = None | Passive (victim visits URL) | Active (victim takes explicit action)

Practical rule: If program uses CVSS 4.0 and you don't know the vector, use the calculator and include the full string starting with CVSS:4.0/AV:.... Programs cannot dispute a valid vector string.

Write to a person, not a system:

• Triagers are tired. Get to the impact in sentence 1.
• Use "I" not "the researcher" — you found it, own it
• Short paragraphs, bullet points for steps
• Hyperlink relevant docs if needed

"This vulnerability does not require any special privileges — only a free account." "The exposed data includes [PII type], which is subject to GDPR requirements." "An attacker can automate this with a simple loop — all [N] records in minutes." "This is exploitable externally without network access to any internal system." "The impact is equivalent to a full data breach of [feature/data type]."

Avoid:

• Jargon the triager might not know
• 5-paragraph explanations of what IDOR is (they know)
• Theoretical chains ("could be combined with X to...")
• Passive voice ("it was observed that...")
• Qualifying language ("seems to," "appears to")

• triage-validation — When deciding whether to write a report at all. Workflow primitive: NEVER open this skill before triage-validation's 7-Question Gate passes; a finding that fails the gate should be killed, not written up.
• bugcrowd-reporting — When the target is a Bugcrowd program. Workflow primitive: this skill's body template is the foundation; bugcrowd-reporting overlays VRT selection, severity-request paragraph, OOS-clause rebuttals on top.
• evidence-hygiene — When PoC screenshots / HARs are being attached to the report. Workflow primitive: every artifact referenced in the "Supporting Materials" / "Proof of Concept" section gets routed through evidence-hygiene for cookie + PII redaction before attachment.
• redteam-report-template — When the engagement is an external red team (NOT bug bounty). Workflow primitive: confirm engagement mode via bb-methodology PART 0; if red-team, swap this skill out for redteam-report-template (different audience, different structure: Subject / Observations / Description / Impact / Recommendation / PoC).

> Engagement-derived additions to the vendored foundation. Wisdom from real > authorized engagements + Phase 2 verification across this repo's 31+ > skill-area live tests. The upstream methodology covers the WHAT; this > layer covers the WHEN-IT-ACTUALLY-WORKS and the FAILURE-MODES.

Title formula in practice

<asset> | <bug class> | <impact> — three components, no fluff. Triagers read titles in roughly three seconds and use them to order the queue.

• BAD: "Interesting finding on /api/users"
• BAD: "IDOR vulnerability in API"
• GOOD: "Authenticated IDOR on /api/users/{uid} -> admin email + role disclosure"
• GOOD: "Unauthenticated SSRF on /preview?url= -> AWS metadata 169.254.169.254 reachable"

What triagers actually read

Their reading sequence on a fresh report:

• Title (3 seconds)
• First paragraph of impact / summary (15 seconds)
• The curl command or HTTP request block (30 seconds)
• Reproduction steps (only if the first three were convincing)
• Everything else (only on follow-up review)

CVSS 3.1 vs Bugcrowd VRT vs H1 default severity

These three systems disagree about 30% of the time. The most common gap: a finding that scores CVSS 7.x (High) maps to Bugcrowd P4 (Low) or H1 Medium-default. When the platform default rates lower than CVSS:

• File the severity-request paragraph as the first body section. Bugcrowd respects this. (See bugcrowd-reporting for the canonical template.)
• Anchor the request in CVSS vector string + business impact, not feelings. "CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N = 7.5 High because Confidentiality:High applies to cross-tenant data exposure."
• Cite the platform's own VRT entry that matches your finding. Don't argue against the platform; route within it.

Evidence rotation

Everything in the submission body is logged forever by the platform. Operate accordingly:

• Use throwaway test accounts created specifically for the engagement.
• Rotate cookies / tokens after each submission (don't reuse the cookie that's pasted in the report).
• Never paste production cookies, real user emails, or real PII into the report body — redact in the PoC step.
• Screenshots of admin panels: blur the user list, blur the URL bar if it contains tokens.

Templates by platform — when they differ

The single biggest report-writing mistake

Claiming an attack works "in theory" or "could be chained to [bigger impact]" without demonstrating it. Triage-validation Q6 (impact beyond technically possible) kills these on the validation side; report-writing has to mirror it on the writing side.

Two valid paths:

• Show concrete impact end-to-end. Capture the chain on a test account. Paste the full request/response sequence. Done.
• Downgrade the severity claim to match what you actually demonstrated. "IDOR on /api/users/{uid} reading email + role" is real and reportable; "IDOR chained to potential admin takeover" is not until you demonstrate the takeover.

• bb-methodology — When Phase 5's report-writing step starts. Workflow primitive: Phase 5 calls /report which loads this skill for the platform-specific template (H1 / Bugcrowd / Intigriti / Immunefi).