web3-triage-report

Name: web3-triage-report
Author: shuvonsec

110stars29forks

How to install web3-triage-report?

shuvonsec/web3-bug-bounty-hunting-ai-skills/web3-triage-report

$npx -y skills add shuvonsec/web3-bug-bounty-hunting-ai-skills --skill web3-triage-report

Installs into the current project.

Summary

Bug triage validation system, Immunefi report format, and 20 real paid bounty examples dissected. Use this when validating a finding before submitting, writing an Immunefi report, checking if a bug is actually valid, or studying real examples of paid vulnerabilities.

Files · 1

View on GitHub

SKILL.md

1	# TRIAGE, REPORT WRITING & REAL EXAMPLES
2
3	---
4
5	## PART 1: TRIAGE
6
7	### THE 7-QUESTION GATE
8
9	Ask these IN ORDER before writing a single word of your report.
10	ONE wrong answer = STOP and move on.
11
12	---
13
14	#### Q1: Can an attacker use this RIGHT NOW, step by step?
15
16	Complete this template:
17	```
18	1. Setup: [what I need]
19	2. Call: [exact function, exact params]
20	3. Result: [what I have that I didn't have before]
21	4. Cost: [gas + capital]
22	5. ROI: [profit / cost ratio]
23	```
24
25	If you cannot complete steps 2 and 3 with specific function calls: KILL IT.
26
27	---
28
29	#### Q2: Is the impact in the program's accepted impact list?
30
31	Go to the Immunefi program page. Find "Impacts in Scope."
32	Match your bug to one of these EXACTLY.
33
34	Example impact tiers:
35	- "Direct theft of any user funds" — Critical
36	- "Permanent freezing of funds" — Critical
37	- "Protocol insolvency" — Critical
38	- "Theft of unclaimed yield" — High
39	- "Permanent freezing of unclaimed yield" — High
40	- "Temporary freezing of funds" — High
41	- "Smart contract unable to operate due to lack of token funds" — Medium
42	- "Griefing (no profit motive, but damage to users)" — Medium
43	- "Contract fails to deliver promised returns, but doesn't lose value" — Low
44
45	If your bug does not match any impact in scope: KILL IT.
46
47	---
48
49	#### Q3: Is the root cause in an in-scope contract?
50
51	Confirm the exact deployed address is in scope on the program page.
52
53	If the bug is in Aave, Uniswap, OpenZeppelin, or any external dependency: KILL IT.
54
55	---
56
57	#### Q4: Does it require admin/privileged access?
58
59	"Admin can drain funds" = centralization risk = KILL IT.
60	"Admin can set parameter X which under condition Y creates DoS" = borderline.
61
62	Salvage path: can the bug trigger WITHOUT the admin doing anything unusual?
63	- If yes: valid
64	- If no: likely invalid (requires admin mistake — almost always out of scope)
65
66	---
67
68	#### Q5: Is this already known/acknowledged in prior audits?
69
70	Find the audit reports for the protocol. Search for "Risk Accepted," "Acknowledged," "Won't Fix."
71
72	If your bug matches a known finding: KILL IT.
73
74	Edge case: if acknowledged finding + NEW code around it creates a new attack path → that is a new bug, not the acknowledged one. Must prove the new path.
75
76	---
77
78	#### Q6: Is the economic attack viable?
79
80	```
81	Attacker spends: gas + capital
82	Attacker gains: tokens stolen or protocol damaged
83
84	If profit < cost: KILL IT.
85	```
86
87	Example:
88	- DoS via dust harvest: costs 1 wei USDC + gas, disables yield for $81K TVL → VIABLE.
89	- Withdraw-fee arbitrage: fee (0.1%) > diluted yield from attack → NOT profitable → KILL IT.
90
91	---
92
93	#### Q7: Is this already public?
94
95	- Is it on social media or in a disclosed report?
96	- Was it previously submitted and disclosed?
97	- Is the "sensitive" data visible in the UI already?
98
99	If yes: KILL IT.
100
101	---
102
103	### THE SEVERITY MATRIX
104
105	Score = Impact × Likelihood × Exploitability (each 1–3)
106
107	\| \| Impact=1 (info leak) \| Impact=2 (partial) \| Impact=3 (theft/freeze) \|
108	\|--\|--\|--\|--\|
109	\| L=1 E=1 \| 1 (Info) \| 2 (Low) \| 3 (Low) \|
110	\| L=2 E=2 \| 4 (Medium) \| 8 (High) \| 12 (High) \|
111	\| L=3 E=3 \| 9 (High) \| 18 (Critical) \| 27 (Critical) \|
112
113	Rule: When borderline, round DOWN. Over-classification destroys credibility.
114
115	---
116
117	### THINK LIKE AN ATTACKER TEMPLATE
118
119	Before writing your report, fill in this attack scenario:
120
121	```
122	Protocol: [name]
123	Target contract: [address + function]
124	Preconditions: [what state must exist?]
125	Attack sequence:
126	1. Attacker calls [exact function] with [exact params]
127	2. [What happens in the contract]
128	3. [What state changes]
129	4. Attacker ends up with: [X more tokens / broken state / DoS]
130	Total cost: [gas estimate + capital requirement]
131	Total gain: [$X stolen / $Y TVL frozen]
132	Viable? [yes/no + reason]
133	```
134
135	If you can't fill in steps 1–4 with specific values, the bug is not ready to submit.
136
137	---
138
139	### THINK LIKE A TRIAGER CHECKLIST
140
141	A triager reviewing your report will immediately check:
142
143	- [ ] Does the title match an accepted impact?
144	- [ ] Is the vulnerable function clearly identified (file + line)?
145	- [ ] Is the root cause explained (not just "there is a bug")?
146	- [ ] Is there comparison evidence ("function A has this, function B doesn't")?
147	- [ ] Does the PoC run without errors?
148	- [ ] Is the severity appropriate to the actual impact?
149	- [ ] Is the bug already in the known issues list?
150	- [ ] Does the fix make sense (proves you understand the root cause)?
151
152	If your report can't pass this checklist: revise before submitting.
153
154	---
155
156	### SEVERITY DOWNGRADE TRIGGERS
157
158	\| Condition \| Severity drops \|
159	\|-----------\|---------------\|
160	\| Requires specific admin configuration \| -1 level \|
161	\| Impact limited to a small subset of users \| -1 level \|
162	\| Requires long time window (>24h) to ex

People who liked this also viewed

6 picks

Type

web3-triage-report

110stars29forks

View on GitHub

How to install web3-triage-report?

shuvonsec/web3-bug-bounty-hunting-ai-skills/web3-triage-report

$npx -y skills add shuvonsec/web3-bug-bounty-hunting-ai-skills --skill web3-triage-report

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# TRIAGE, REPORT WRITING & REAL EXAMPLES
2
3	---
4
5	## PART 1: TRIAGE
6
7	### THE 7-QUESTION GATE
8
9	Ask these IN ORDER before writing a single word of your report.
10	ONE wrong answer = STOP and move on.
11
12	---
13
14	#### Q1: Can an attacker use this RIGHT NOW, step by step?
15
16	Complete this template:
17	```
18	1. Setup: [what I need]
19	2. Call: [exact function, exact params]
20	3. Result: [what I have that I didn't have before]
21	4. Cost: [gas + capital]
22	5. ROI: [profit / cost ratio]
23	```
24
25	If you cannot complete steps 2 and 3 with specific function calls: KILL IT.
26
27	---
28
29	#### Q2: Is the impact in the program's accepted impact list?
30
31	Go to the Immunefi program page. Find "Impacts in Scope."
32	Match your bug to one of these EXACTLY.
33
34	Example impact tiers:
35	- "Direct theft of any user funds" — Critical
36	- "Permanent freezing of funds" — Critical
37	- "Protocol insolvency" — Critical
38	- "Theft of unclaimed yield" — High
39	- "Permanent freezing of unclaimed yield" — High
40	- "Temporary freezing of funds" — High
41	- "Smart contract unable to operate due to lack of token funds" — Medium
42	- "Griefing (no profit motive, but damage to users)" — Medium
43	- "Contract fails to deliver promised returns, but doesn't lose value" — Low
44
45	If your bug does not match any impact in scope: KILL IT.
46
47	---
48
49	#### Q3: Is the root cause in an in-scope contract?
50
51	Confirm the exact deployed address is in scope on the program page.
52
53	If the bug is in Aave, Uniswap, OpenZeppelin, or any external dependency: KILL IT.
54
55	---
56
57	#### Q4: Does it require admin/privileged access?
58
59	"Admin can drain funds" = centralization risk = KILL IT.
60	"Admin can set parameter X which under condition Y creates DoS" = borderline.
61
62	Salvage path: can the bug trigger WITHOUT the admin doing anything unusual?
63	- If yes: valid
64	- If no: likely invalid (requires admin mistake — almost always out of scope)
65
66	---
67
68	#### Q5: Is this already known/acknowledged in prior audits?
69
70	Find the audit reports for the protocol. Search for "Risk Accepted," "Acknowledged," "Won't Fix."
71
72	If your bug matches a known finding: KILL IT.
73
74	Edge case: if acknowledged finding + NEW code around it creates a new attack path → that is a new bug, not the acknowledged one. Must prove the new path.
75
76	---
77
78	#### Q6: Is the economic attack viable?
79
80	```
81	Attacker spends: gas + capital
82	Attacker gains: tokens stolen or protocol damaged
83
84	If profit < cost: KILL IT.
85	```
86
87	Example:
88	- DoS via dust harvest: costs 1 wei USDC + gas, disables yield for $81K TVL → VIABLE.
89	- Withdraw-fee arbitrage: fee (0.1%) > diluted yield from attack → NOT profitable → KILL IT.
90
91	---
92
93	#### Q7: Is this already public?
94
95	- Is it on social media or in a disclosed report?
96	- Was it previously submitted and disclosed?
97	- Is the "sensitive" data visible in the UI already?
98
99	If yes: KILL IT.
100
101	---
102
103	### THE SEVERITY MATRIX
104
105	Score = Impact × Likelihood × Exploitability (each 1–3)
106
107	\| \| Impact=1 (info leak) \| Impact=2 (partial) \| Impact=3 (theft/freeze) \|
108	\|--\|--\|--\|--\|
109	\| L=1 E=1 \| 1 (Info) \| 2 (Low) \| 3 (Low) \|
110	\| L=2 E=2 \| 4 (Medium) \| 8 (High) \| 12 (High) \|
111	\| L=3 E=3 \| 9 (High) \| 18 (Critical) \| 27 (Critical) \|
112
113	Rule: When borderline, round DOWN. Over-classification destroys credibility.
114
115	---
116
117	### THINK LIKE AN ATTACKER TEMPLATE
118
119	Before writing your report, fill in this attack scenario:
120
121	```
122	Protocol: [name]
123	Target contract: [address + function]
124	Preconditions: [what state must exist?]
125	Attack sequence:
126	1. Attacker calls [exact function] with [exact params]
127	2. [What happens in the contract]
128	3. [What state changes]
129	4. Attacker ends up with: [X more tokens / broken state / DoS]
130	Total cost: [gas estimate + capital requirement]
131	Total gain: [$X stolen / $Y TVL frozen]
132	Viable? [yes/no + reason]
133	```
134
135	If you can't fill in steps 1–4 with specific values, the bug is not ready to submit.
136
137	---
138
139	### THINK LIKE A TRIAGER CHECKLIST
140
141	A triager reviewing your report will immediately check:
142
143	- [ ] Does the title match an accepted impact?
144	- [ ] Is the vulnerable function clearly identified (file + line)?
145	- [ ] Is the root cause explained (not just "there is a bug")?
146	- [ ] Is there comparison evidence ("function A has this, function B doesn't")?
147	- [ ] Does the PoC run without errors?
148	- [ ] Is the severity appropriate to the actual impact?
149	- [ ] Is the bug already in the known issues list?
150	- [ ] Does the fix make sense (proves you understand the root cause)?
151
152	If your report can't pass this checklist: revise before submitting.
153
154	---
155
156	### SEVERITY DOWNGRADE TRIGGERS
157
158	\| Condition \| Severity drops \|
159	\|-----------\|---------------\|
160	\| Requires specific admin configuration \| -1 level \|
161	\| Impact limited to a small subset of users \| -1 level \|
162	\| Requires long time window (>24h) to ex

People who liked this also viewed

6 picks

Type