How to Report a Smart Contract Vulnerability Safely

By Owen Thurm Published November 6, 2026 6 min read

Quick answer. With no bounty, look for SECURITY.md, GitHub private reporting or security.txt. Send the impact, affected addresses and a PoC run on a fork. Never test on mainnet or publish first. If funds are draining now, contact SEAL 911.

Watch: How to Report a Smart Contract Vulnerability Safely 1:37

Video transcript

You found a bug in a live contract. What you do next decides whether users stay safe, and whether you do.

Find a private channel, in this order: a bug bounty page, a security dot M D file, GitHub private reporting, then security dot T X T.

If funds are draining now, do not wait. Contact SEAL nine one one, a free, around-the-clock emergency hotline.

No contact listed? Ask a core contributor for a private channel. Your first message says only that you found an issue, which contract, a severity estimate and how to reach you.

The report names the chain, addresses, impact and root cause, plus a proof of concept on a local fork and your severity rating. Thin reports get rejected.

Never test on mainnet or a public testnet, move live funds without written approval, go public before a fix, or make threats. Prove it on a fork.

This is not legal advice. Read a policy's safe harbor before you test. Since May 2022, US policy tells prosecutors to decline good-faith research cases, but not extortion. Keep dated records.

After a Vanguard audit, a public Defender contest opens the scope to researchers. Guardian funds a one hundred thousand dollar Critical pot.

Read the full guide, or talk to Guardian at guardian.security about giving researchers a safe way to reach you.

You found a bug in a live contract. What you do next decides whether users stay safe, and whether you do.

The steps below draw on published rules from RFC 9116, GitHub, CISA, Immunefi, the US Justice Department and the Security Alliance (SEAL).

Find the Right Channel

Look for a private channel, in this order:

Bug bounty page: on a platform such as Immunefi or Cantina, or the team's own site.
SECURITY.md: in the repository. It "tells reporters how to submit vulnerabilities", in SEAL's words.
GitHub private reporting: a "Report a vulnerability" button on the repository's "Security and quality" tab, where enabled.
security.txt: at /.well-known/security.txt on the team's website. RFC 9116 requires a Contact field.

If a bounty platform hosts the program, report there. Immunefi's rules ban "Submitting bugs via email or any channel other than the Immunefi platform."

Is it being exploited now?

If funds are draining, or an attack looks imminent, do not wait for a reply.

SEAL 911 is "a free, around-the-clock emergency hotline" for anyone facing "an active or imminent security incident." Its GitHub repository gives the Telegram bot, @seal_911_bot.

Check the handle against that repository before you message. See what SEAL 911 is.

No Bounty, No Contact

SEAL's framework warns that without a security contact, "findings route through public issues, social media, or nowhere".

So find a private route first:

Check the docs, the website footer and the repository for a security email or form.
If GitHub private reporting is off, GitHub suggests an issue asking for a security contact. Put no details in it.
Message a core contributor on a public profile, and ask for a private channel.

Your first message should say only this: you found a security issue, which contract it affects, a severity estimate and how to reach you.

Hold the details until a private channel is confirmed. A bug posted where an attacker can read it is a disclosure.

Writing the Report

GitHub's private report form asks for a summary, details, a proof of concept and an impact statement by default.

CISA's template asks for the location, the potential impact and "a detailed description of the steps needed to reproduce the vulnerability".

For a smart contract, include:

Title: one line naming the bug and its impact.
Affected deployments: chain, contract addresses and the verified source or commit.
Impact: what an attacker gains, and the funds at risk now.
Root cause: the function, the line and why the check fails.
Proof of concept: a test on a local fork that anyone can run.
Severity: your rating against the program's table, if it has one.
Fix: a suggested patch, if you have one.

Thin reports get rejected. Immunefi bans placeholder reports with "a vague title, very few details, and no reproducible steps".

GMX's program requires a proof of concept "for all severities." To build one, see how to write a smart contract PoC.

What Never to Do

Testing on mainnet or a public testnet. Immunefi calls it "grounds for an immediate and permanent ban."
Testing against pricing oracles or third-party contracts. Both are off-limits in Immunefi's default terms.
Moving live funds to "save" them. Immunefi bans whitehacking without the project's written approval.
Going public before a fix. Immunefi bans disclosing a report, "or even the existence of a bug report", before it is fixed and the whitehat paid.
Threats. Immunefi bans "Extortion/blackmail or threats of extortion/blackmail".
Taking more than you need. CISA: "Only use exploits to the extent necessary to confirm a vulnerability's presence."

A bug you cannot show without real funds can still be proven. Fork the chain at a recent block and run the attack there.

Protecting Yourself

This section explains published policies. It is not legal advice; if a team threatens action, talk to a lawyer.

The policy's safe harbor

A disclosure policy can authorize your research in advance. CISA's template shows how.

If you make "a good faith effort to comply with this policy," the agency "will not recommend or pursue legal action related to your research."

That covers only research that follows the policy. Read it before you test.

US prosecution policy

Since May 2022, the US Justice Manual has told federal prosecutors they "should decline prosecution" of good-faith security research under the Computer Fraud and Abuse Act.

The policy's definition requires research "carried out in a manner designed to avoid any harm to individuals or the public."

It excludes extortion. Research done to "extort the owners" of a system "might be called 'research,' but is not in good faith."

SEAL Safe Harbor, for live exploits

SEAL Safe Harbor lets whitehats rescue funds during an exploit, under terms a protocol publishes in advance.

It applies only "when an exploit is already in progress or imminent."
It covers only protocols that adopted it, and only the contracts and chains in their scope.
Rescued funds go to the protocol's recovery address within 72 hours, per SEAL's site summary.
Whitehats "should reach out within 6 hours of a rescue," per SEAL's scope terms.
It protects only whitehats "fully independent from the original exploit."

SEAL's page sets bounties "at 10% of recovered assets (capped at $1M)". A bug no one is exploiting goes through disclosure, not Safe Harbor.

Keep records

Save dated copies of every message, your report and your PoC. If a dispute comes later, the timeline is your evidence.

If the Team Does Not Respond

Silence is not permission. Work through these steps in order:

Follow up on a fixed schedule, through a second channel.
On a platform, ask the platform to step in.
CERT/CC says it "may be able to provide assistance for reports when the coordination process breaks down."
Before going public, give the team a date. CISA's template asks for "a reasonable amount of time" first.

Platforms set their own limits. HackerOne's last-resort rule allows disclosure after 180 days without a response, with follow-ups at least every 30 days.

An immutable contract cannot be patched in place. If you publish, describe the bug class and warn users, but hold back a working exploit.

Reporting to Guardian Clients

Some protocols run their bounty through Guardian. With Vanguard, Guardian hosts and manages the bug bounty, with tuned AI triage and known issue tracking.

Under Managed Security, Guardian handles every report "from submission to close or drafted fix".

After a Vanguard audit, a public Defender contest opens the audited scope to independent researchers and AI auditors. Guardian funds a $100,000 Critical pot.

The bounty contest terms set the rules:

Two judges, one named by Guardian and one by the protocol, must agree a finding is Critical.
Only the first validated report of a Critical is eligible.
Payout needs KYC, any required tax documentation and payment details.
Tampering with live or testnet contracts disqualifies you.

Run a protocol? Publish a policy first with our vulnerability disclosure policy template.

Frequently Asked Questions

How do I report a smart contract bug when there is no bug bounty?

Look for SECURITY.md, GitHub private reporting or a security.txt file. If none exists, ask the team for a private channel before sending details. Then send the impact, affected addresses and a PoC run on a local fork.

Can I move funds to prove or protect them?

Only with the project's written consent, or under SEAL Safe Harbor at an adopting protocol during an active or imminent exploit. SEAL's site summary gives 72 hours to return rescued funds. Otherwise, report the bug.

When can I disclose a vulnerability publicly?

After the fix, if the program allows it. Immunefi bans disclosure before a bug is fixed and the whitehat paid. HackerOne's last-resort rule allows disclosure after 180 days without a response, despite follow-ups at least every 30 days.

Is SEAL 911 for bug reports?

It is an emergency hotline for active or imminent security incidents. For a bug no one is exploiting, use the team's own channel.

Sources

Give researchers a safe way to reach you

With Vanguard, Guardian hosts and manages your bug bounty, with tuned AI triage tied to the audit.

Talk to Guardian Read the bounty contest terms