report-writing – Writing & Content skill for AI agents

REPORT WRITING

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

---

THE MOST IMPORTANT RULE

> 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:
       [email protected] (ID 123) successfully retrieved [email protected] (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

## 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: [email protected], user_id = 123
- Victim account: [email protected], user_id = 456
- Target: https://target.com

**Steps:**

1. Log in as [email protected], 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:

{

"orders": [

{"id": 789, "items": [...], "email": "[email protected]", "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:

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

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

# [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 protected] (standard account, no special role)
- Victim: [email protected]
- Tested: [date]

**Reproduction steps:**

1. [Login as attacker / visit URL / send request]

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

\

3. Observe response contains victim's private data:

\

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

---

IMMUNEFI REPORT TEMPLATE

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

// 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)

Metric Quick Picks

| Metric | Value | Weight | When |

|---|---|---|---|

| Attack Vector (AV) | Network | +0.85 | Via internet |

| | Local | +0.55 | Local access needed |

| Attack Complexity (AC) | Low | +0.77 | Repeatable |

| | High | +0.44 | Race/timing needed |

| Privileges Required (PR) | None | +0.85 | No login |

| | Low | +0.62 | Regular user account |

| | High | +0.27 | Admin account |

| User Interaction (UI) | None | +0.85 | No victim action |

| | Required | +0.62 | Victim must click |

| Scope (S) | Changed | higher | Affects browser/OS/other |

| | Unchanged | lower | Stays in app |

| Confidentiality (C) | High | +0.56 | All data exposed |

| | Low | +0.22 | Limited data |

| Integrity (I) | High | +0.56 | Can modify any data |

| Availability (A) | High | +0.56 | Crashes service |

Typical Scores by Bug Class

| Bug | Typical CVSS | Severity |

|---|---|---|

| IDOR (read PII) | 6.5 | Medium |

| IDOR (write/delete) | 7.5 | High |

| Auth bypass → admin | 9.8 | Critical |

| Stored XSS (any user) | 5.4–8.8 | Med–High |

| SQLi (data exfil) | 8.6 | High |

| SSRF (cloud metadata) | 9.1 | Critical |

| Race condition (double spend) | 7.5 | High |

| GraphQL auth bypass | 8.7 | High |

| JWT none algorithm | 9.1 | Critical |

---

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 lim

… (full content is in the download package)