We manage your security to weather the AI storm →

← Resource Hub

Vulnerability Triage for a Critical Bug in Live Contracts

By Owen Thurm Published 6 min read

Vulnerability Triage for a Critical Bug in Live Contracts

Quick answer. Acknowledge the report quickly (teams often target 24 hours) and reproduce it on a mainnet fork. Rate its severity, contain it quietly, fix it privately, pay the reporter as promised, and disclose after the fix is live.

Watch: Vulnerability Triage for a Critical Bug in Live Contracts 1:42
Video transcript

A critical bug report on live contracts starts a race. Someone else can find the same bug, and some do.

In December 2021, a second whitehat reported Polygon's MRC20 bug a day after the first. A blackhat took 801,601 MATIC before the fix landed, per Immunefi.

Acknowledge fast, teams often target 24 hours. Reproduce the proof of concept on a pinned mainnet fork. Then rate severity, contain quietly, fix privately, and pay and disclose.

A pause is public. Anyone watching the chain can see which function stopped and start looking there.

Match the response to exposure. If it is being exploited, pause and call SEAL nine one one. If anyone can trigger it, mitigate narrowly within hours. If it needs a privileged role, fix privately on a planned schedule.

Write the fix in a private fork, because public commits can leak a bug. The reporter's exploit must fail on the patch, then becomes a regression test. Get an independent review, and simulate the upgrade first.

Pay what the program promised. Immunefi bans stealth fixes without full payment, and disclosure comes only after the fix and the payment.

Guardian's 320 public audit reports include 343 Critical findings. Under Managed Security, Guardian handles reports from submission to close or drafted fix.

Vanguard adds a hosted bounty with AI triage and fifty thousand dollars in Critical matching. Read the full guide, or talk to Guardian.

A critical report on live contracts starts a race. Someone else can find the same bug, and some do.

In December 2021, a second whitehat reported Polygon's MRC20 bug a day after the first. A blackhat used it to take 801,601 MATIC before the fix landed, per Immunefi.

This guide covers the protocol's side, from the first message to disclosure. Reporters should read how to report a smart contract vulnerability.

If funds are draining now, switch to your incident response plan.

Acknowledge and Reproduce

SEAL's guidance is to "acknowledge receipt quickly (teams often target within 24 hours)". The inbox needs people who can triage.

The first reply can be short:

  • Confirm you received it, and name who owns it.
  • Ask for anything missing: chain, addresses, PoC.
  • Say when the next update comes.

On a platform, keep everything there. Immunefi's rules say negotiations outside its dashboard "are considered invalid".

Reproduce on a fork

Run the reporter's PoC against a fork of mainnet, never against live contracts. In Foundry's words, fork testing "lets you run tests against real chain state without deploying to a live network."

Pin the fork with --fork-block-number, so every engineer sees the same state.

Check that the deployed bytecode matches the source the reporter read. Then confirm the impact holds at current balances and settings.

Speed is possible. Notional confirmed a critical report in under an hour, per Immunefi.

Known or duplicate?

If you think it is known, prove it. Immunefi bans "Claiming a bug report is a known or duplicate issue without clear evidence."

Assess Severity and Exposure

Rate the bug against the severity table your program published, not a fresh judgment made under pressure.

Under Immunefi's v2.3 classification, Critical smart contract impacts include:

  • "Direct theft of any user funds, whether at-rest or in-motion, other than unclaimed yield"
  • "Permanent freezing of funds"
  • "Protocol insolvency"

Then size the exposure. Answer these before choosing a response:

  • Can anyone trigger it, without a privileged role?
  • How much is directly at risk right now?
  • Which chains, deployments and forks share the code?
  • Has it been triggered already? Check chain history.
  • Can the fix ship without a public signal?

Forks matter. When Jay Freeman reported Optimism's l2geth bug, Optimism had already contacted Boba and Metis, two forks, he wrote.

So does history. Freeman found one user had triggered the bug on Christmas Eve 2021, but judged they "hadn't realized it was exploitable."

Contain Without Tipping Off

SEAL's advice is to "treat reports as confidential until a fix is in place". The exception is a coordinated public path or Safe Harbor scenario that "requires faster warning".

A pause is public. Anyone watching the chain can see which function stopped and start looking there.

SituationDefault response
Being exploited nowPause, contact SEAL 911, run the incident plan
Anyone can trigger it; no sign of useNarrow mitigation within hours, full fix fast
Fix needs days and exposure is largeConsider a scoped pause, accepting the signal
Needs a privileged role or rare statePrivate fix on a short, planned schedule

Narrow mitigations exist. Moonbeam first shipped a runtime that disabled all DELEGATECALL use, then restored it for everything except custom precompiles.

Notional removed the flawed feature by upgrade first. It shipped a proper fix and re-enabled the feature later.

Design the pause before you need it. See pausable contract design.

Fix, Verify and Deploy

Write the fix where attackers cannot read it. GitHub's temporary private forks exist "to privately collaborate on fixing a security vulnerability in your public repository."

CI cannot access those forks, per GitHub, so run the full suite locally.

Public commits can leak a bug. Freeman wrote that Optimism's fix "slightly hid this update in a pile of other updates" to give unknown forks time.

Verify before deploying

  • Run the reporter's PoC on the patched fork. It must fail.
  • Keep the PoC as a permanent regression test.
  • Ask the reporter to try to break the fix.
  • Get an independent review of the diff and the upgrade transaction.
  • Simulate the deploy or upgrade on a fork first.

Published timelines

ProgramReportedFixed
WormholeFeb 24, 2022Same day
Polygon MRC20Dec 3, 2021Fix submitted Dec 5
Polygon Plasma bridgeOct 5, 2021Mitigated within one week
zkSync LiteOct 5, 2023Fix applied Nov 7, 2023

Two days was still too slow at Polygon. Treat every hour before the fix as exposure.

Pay the Reporter

Pay what the program promises. Immunefi bans projects from "stealth fixing the bug later without providing full payment to the whitehat."

It also bans "Breaking SLAs regarding responsiveness and bug report resolution." A project that does can be removed, with the removal published.

Settle the terms in your policy, before a report arrives:

  • Currency: Polygon paid $2.2 million in stablecoins; Aurora paid $6 million in AURORA tokens.
  • KYC: GMX's Immunefi program requires none; Guardian's bounty contest requires it.
  • Edge cases: Optimism paid its full $2,000,042 for a bug its listed bounty did not cover.

To size the reward, use our bug bounty payout calculator. Our list of the biggest crypto bug bounties shows the top end.

Coordinate Disclosure

Disclose after the fix and the payment. Immunefi bans projects from "Publicly disclosing a bug report before you have both fixed the issue and paid the whitehat".

When the whitehat may publish depends on the program's category, per Immunefi:

  • Category 1: at will, once fixed and paid.
  • Category 2: after a 21-day project notice and review.
  • Category 3: only with explicit project approval.
  • Any category: at will if unresolved 90 days after escalation, unless mediation is ongoing.

SEAL asks teams to "publish disclosure process and expected timelines," and to credit researchers only with their permission.

Write-ups often follow weeks later. Aurora's report came on April 26, 2022, and its public post on June 7.

A good write-up names the affected versions, the impact, the fix, whether it was exploited, and the reporter, if they agree.

How Guardian Handles Reports

Under Managed Security, Guardian handles every report "from submission to close or drafted fix", including triage, impact validation and severity disputes.

With Vanguard, Guardian hosts the bounty with tuned AI triage and known issue tracking tied to the audit, plus $50,000 in Critical matching.

Vanguard also reviews changes to the audited scope for six months after production, up to 2,500 smart contract SLOC. Fixes count as changes.

Guardian's 320 public audit reports include 343 Critical findings.

Frequently Asked Questions

How fast should a protocol respond to a critical bug report?

SEAL says to acknowledge receipt quickly, noting that teams often target 24 hours. Published fixes range from the same day at Wormhole to about a month at zkSync Lite. A bug anyone can trigger needs containment within hours.

Should we pause the protocol after a critical report?

Pause at once if the bug is being exploited. Otherwise weigh it: a pause is public and can point attackers at the bug, so a narrow mitigation or a fast private fix is often safer.

Can a protocol fix a reported bug without paying?

Not on Immunefi. Its rules ban stealth-fixing a bug "without providing full payment to the whitehat," and projects that break SLAs can be removed from the platform, with the removal published.

When can a critical bug be disclosed?

After it is fixed and the whitehat is paid, under Immunefi's rules. Depending on the program's category, the whitehat may then publish at will, after a 21-day project review, or only with project approval.

Sources

Have Guardian triage your next critical report

Guardian hosts your bounty, validates every report against your system and drafts the fix, so a critical report never waits on your team alone.