Critical or Nah? Understanding What Counts in Web3 Bug Bounties

Bug bounty hunting in Web3 is an art just as much as it is a science. When you’re deep in contract analysis, testing exploits, and assembling the perfect Proof of Concept (PoC), everything can feel critical—especially when user funds move, approvals are hijacked, or vaults are drained. But here’s the kicker: not everything that feels critical is actually considered critical by the platform reviewing your report.

Let’s talk about why.

“Looks Critical to Me” vs “Meets Program Scope”

One of the most frustrating things for security researchers is discovering a vulnerability that clearly demonstrates a dangerous behavior, like unauthorized token transfers, but having it ruled as “non-critical” or worse, a “non-vulnerability.”

That’s what happened recently in a bounty competition I participated in. After building a full exploit involving router manipulation and approval hijacking, I submitted what I believed to be a solid critical report.

The logic was simple:

1. A user approves a contract for a zap operation.

2. An attacker swaps the router to a malicious one.

3. The malicious router calls approve() to grant itself allowance.

4. Tokens are drained into a vault without user re-approval.

Sounds pretty serious, right?

But the issue?
The ability to set the malicious router was gated behind an onlyOwner modifier.
So unless the owner is malicious or the contract is misconfigured, this exploit path doesn't exist in production.

Understanding “In Scope”

Bug bounty platforms like Immunefi are very specific:

A bug must affect production, be realistically exploitable, and not require privileged access unless otherwise stated.

Even if your attack can drain tokens, if the setup depends on being the contract owner, it won't be accepted as a valid finding. Unless the contract is ownerless, permissionless, or misconfigured, you're outside the “critical” scope.

So What Is Critical?

Critical bugs usually meet these criteria:

• No privileged roles required

• Direct theft of user funds

• Unintended token approvals / transfers that anyone can trigger

• Bypassing authentication or permission checks

• Protocol insolvency from manipulation (e.g., draining reward pools)

If your bug doesn’t meet those rules, it may still be valuable—but not “critical.”

Lessons Learned

• Always cross-check the exploit path against roles and access control.

• Validate your assumptions about who can trigger each call.

• When in doubt, include proof of public accessibility in your PoC.

• If you’re reporting something nuanced, consider submitting it as an Insight instead of a bug.

Final Thoughts

Every rejected bug is a lesson. You level up by failing forward, refining your eyes for scope, and sharpening your exploit logic.

Keep building. Keep testing. And when your next critical bug hits? You’ll know exactly why it counts.