Immunefi bug report template

Ten sections in the order Immunefi asks for them, with the impact quoted from the programme and a proof of concept that runs on a local fork. Copy it, fill every placeholder, then send the draft to the workbench before the triager sees it.

Download .md

Rules checked 2 Oct 2026 · 5 sources

The template

Immunefi’s form takes the title, the asset and the impact as separate fields. The first line below goes in the title field. The rest goes in the description.

Platformasked for in Immunefi’s published guidance. Addedanswers the two objections that close reports late: overclaiming and known issues.

immunefi.md10 sections
01Platform

Title

One sentence: the vulnerability class, the function, the consequence. Immunefi’s own examples follow that shape. Take the consequence from the programme’s impact list so the title and the selected impact agree.

Vulnerability class in function lets actor consequence, worded as the programme words the impact

02Platform

Brief/Intro

One paragraph. What is broken and what happens if it is used on mainnet. The triager decides here whether to read the rest.

What is broken, in which contract, and what an attacker does with it. Then the consequence: whose funds, how much, at which block.

03Platform

Vulnerability Details

Pin the code. The asset has to be on the programme’s list, and the lines have to exist at the commit the deployed contract was built from. Number the attack steps and name the actor on each one.

  • Asset in scope: name and address, exactly as listed under Assets in Scope
  • Source: repository URL at commit 40-character commit
  • Location: path/Contract.sol lines start-end, function name
  • Deployed code matches this commit: how you checked: verified source, bytecode hash or release tag

Root cause: the one line or missing check that opens the path, and why the surrounding checks do not stop it

{The smallest excerpt that shows the root cause, with its line numbers}

Attack path:

  1. Actor calls function with concrete arguments. State after the call.
  2. Actor calls function with concrete arguments. State after the call.
  3. Final state: the balance, owner or record that is now wrong, with the number.

Every step is a public call from an account that holds no role. If a step needs a role, a signature or an action by the victim, name it here.

04Platform

Impact

Quote the impact from the programme’s Impacts in Scope, word for word. Immunefi lists selecting an impact that does not apply as prohibited behaviour. Put the measured loss next to the quote.

  • Impact selected, quoted from the programme: "exact text of the impact"
  • Severity that impact sits under in the programme's table: Critical, High, Medium or Low
  • Who loses: users, the protocol or liquidity providers lose amount and token of total at risk at the fork block
  • Loss measured by the PoC: the number from the output below
  • Recovery: whether a pause, an upgrade or an admin action returns the funds, and how long that takes
05Platform

Risk Breakdown

How hard the attack is to carry out. Immunefi asks for its own severity classification here in place of a CVSS score. Read the programme’s feasibility limits and downgrade clauses before you claim the tier.

  • Difficulty: capital needed, timing, number of transactions
  • Preconditions, and how each is reached from live state: list
  • Privileges or user interaction needed: none, or which
  • Programme downgrade clauses checked: the clause, and why it does or does not apply
06Platform

Recommendation

The fix, as a diff where it fits. A concrete fix shows the root cause is understood.

The change, in the file and function it belongs to.

- {vulnerable line}
+ {fixed line}
07Platform

Proof of Concept

Runnable code on a local fork, the command, and the pasted output. A numbered list of steps or pseudocode does not count as a PoC on Immunefi. Running the exploit against mainnet or a public testnet is grounds for a permanent ban.

Runs on a local fork. No transaction was sent to mainnet or a public testnet.

  • File: test/ImpactPoC.t.sol
  • Fork: chain at block number
  • Command: forge test --match-path test/ImpactPoC.t.sol -vvv
{The full test file}

Output:

{Pasted output, with the final assertion and the measured numbers}

Control: the same sequence without the bug step, and its output: no loss After the fix: the same test on the patched build, and its failing line

08Added

Limits and non-claims

State what the report does not claim before the triager asks. Immunefi lists misrepresenting severity as prohibited behaviour. Writing the limits yourself keeps the claim inside what the PoC asserts.

  • Not claimed: what this report does not say, for example no loss beyond the funds held at this address
  • Mocked or assumed: each mock and assumption, or "nothing: every step runs the deployed code"
  • Stops working when: the condition that breaks the path
09Added

Known issues checked

Programmes exclude issues they have acknowledged and unfixed findings from the audits they link. Name the nearest one and say why this is a different root cause.

  • Programme known issues and acknowledged risks: date checked, the nearest item, why this differs
  • Audits linked by the programme: report and finding id, why the root cause or the fix differs
  • Public issues, pull requests and team branches: what you searched, the nearest match, the difference
10Platform

References

Links only: the code at the pinned commit, the documentation that defines expected behaviour, the deployed contract.

  • Code at the pinned commit
  • Documentation or specification the expected behaviour comes from
  • Deployed contract on the block explorer
Markdown sourceimmunefi.md
immunefi.md
> Immunefi report template from https://bountyoperator.com/templates/immunefi. Platform rules checked 2 Oct 2026.
> Replace every {placeholder}. Delete this note before you submit.

# {Vulnerability class} in `{function}` lets {actor} {consequence, worded as the programme words the impact}

## Brief/Intro

{What is broken, in which contract, and what an attacker does with it. Then the consequence: whose funds, how much, at which block.}

## Vulnerability Details

- Asset in scope: {name and address, exactly as listed under Assets in Scope}
- Source: {repository URL} at commit `{40-character commit}`
- Location: `{path/Contract.sol}` lines {start}-{end}, function `{name}`
- Deployed code matches this commit: {how you checked: verified source, bytecode hash or release tag}

Root cause: {the one line or missing check that opens the path, and why the surrounding checks do not stop it}

```solidity
{The smallest excerpt that shows the root cause, with its line numbers}
```

Attack path:

1. {Actor} calls `{function}` with {concrete arguments}. {State after the call.}
2. {Actor} calls `{function}` with {concrete arguments}. {State after the call.}
3. {Final state: the balance, owner or record that is now wrong, with the number.}

Every step is a public call from an account that holds no role. {If a step needs a role, a signature or an action by the victim, name it here.}

## Impact

- Impact selected, quoted from the programme: "{exact text of the impact}"
- Severity that impact sits under in the programme's table: {Critical, High, Medium or Low}
- Who loses: {users, the protocol or liquidity providers} lose {amount and token} of {total at risk at the fork block}
- Loss measured by the PoC: {the number from the output below}
- Recovery: {whether a pause, an upgrade or an admin action returns the funds, and how long that takes}

## Risk Breakdown

- Difficulty: {capital needed, timing, number of transactions}
- Preconditions, and how each is reached from live state: {list}
- Privileges or user interaction needed: {none, or which}
- Programme downgrade clauses checked: {the clause, and why it does or does not apply}

## Recommendation

{The change, in the file and function it belongs to.}

```diff
- {vulnerable line}
+ {fixed line}
```

## Proof of Concept

Runs on a local fork. No transaction was sent to mainnet or a public testnet.

- File: `{test/ImpactPoC.t.sol}`
- Fork: {chain} at block {number}
- Command: `{forge test --match-path test/ImpactPoC.t.sol -vvv}`

```solidity
{The full test file}
```

Output:

```text
{Pasted output, with the final assertion and the measured numbers}
```

Control: {the same sequence without the bug step, and its output: no loss}
After the fix: {the same test on the patched build, and its failing line}

## Limits and non-claims

- Not claimed: {what this report does not say, for example no loss beyond the funds held at this address}
- Mocked or assumed: {each mock and assumption, or "nothing: every step runs the deployed code"}
- Stops working when: {the condition that breaks the path}

## Known issues checked

- Programme known issues and acknowledged risks: {date checked, the nearest item, why this differs}
- Audits linked by the programme: {report and finding id, why the root cause or the fix differs}
- Public issues, pull requests and team branches: {what you searched, the nearest match, the difference}

## References

- {Code at the pinned commit}
- {Documentation or specification the expected behaviour comes from}
- {Deployed contract on the block explorer}

What gets this closed on Immunefi

Each reason comes from a page Immunefi publishes. The programme or contest page adds its own rules on top, and those win.

  1. No PoC, or one that does not run

    Submitting without a PoC, or with an incomplete one, where the programme requires it is on Immunefi’s list of prohibited behaviour. Programme terms add that such a report gets no reward. Immunefi’s guide says what a PoC is not:

    Not a list of steps

    How to Submit Bug Reports That Get Paid, Immunefi

    Source Immunefi Rules, How to Submit Bug Reports That Get Paid, Immunefi’s own bug bounty programme terms

  2. Testing on mainnet or a public testnet

    Grounds for an immediate and permanent ban. Every PoC runs on a local fork.

    Source Immunefi Rules

  3. An impact, asset or severity that does not apply

    Claiming an asset that is not in scope, selecting an impact that does not apply, or rating a bug Critical when it is not are each listed as prohibited behaviour. Quote the impact row and match every clause of it to something the PoC shows.

    Source Immunefi Rules

  4. Known issues and unfixed audit findings

    Programmes publish the issues they have acknowledged and link their audits. A finding already listed there, or left unfixed in a linked audit, is not eligible. Reporting a bug that is already public is prohibited.

    Source Immunefi’s own bug bounty programme terms, Immunefi Rules

  5. Default out-of-scope impacts

    Unless the programme says otherwise: attacks that need a privileged address or leaked keys, wrong data supplied by a third-party oracle, 51% and Sybil attacks, lack of liquidity, centralisation risks, and best-practice recommendations. Oracle manipulation and flash-loan attacks are not excluded by that list.

    Source Vulnerability Severity Classification System v2.3

  6. Severity qualifiers

    Severity follows the consequence. When the exploit needs elevated privileges or uncommon user interaction, the level drops or the report is rejected. Programmes add feasibility limits of their own, such as a one-level downgrade when the attack depends on another protocol.

    Source Vulnerability Severity Classification System v2.3, Immunefi’s own bug bounty programme terms

  7. Placeholder and scanner reports

    A vague title, few details and no reproducible steps is a placeholder submission. AI-generated or scanner output that does not show the impact on the reported asset is prohibited, and so is a second report of your own bug filed to claim another reward.

    Source Immunefi Rules

  8. Penalties

    The rules page publishes no submission fee. Breaking the rules costs a temporary suspension or a permanent ban, loss of access to the report, and zero payout.

    Source Immunefi Rules

Challenge the filled draft

Paste the report once every placeholder is replaced. The workbench opens with Challenge a draft report selected and argues against each claim: the impact row, the proof, the severity, the known issues. You decide what to rewrite.

The draft stays in this browser. It is sent only when you run a review in the workbench.

Sources

Primary sources only, read on 2 Oct 2026. Rules change. Read the programme page on the day you submit.