Business logic vulnerabilities in disclosed bug bounty reports

The code does exactly what it was written to do, and what it was written to do is wrong.

Reports indexed
1702
Total paid
$131k
Critical
1
Largest payout
$120k

Logic errors are the residual category and the hardest to find with tooling, because there is no unsafe pattern to grep for. The contract compiles, the tests pass, and the specification itself has a hole in it: an off-by-one in a reward epoch, a state machine that permits a transition nobody considered, an accounting path that credits twice under a specific ordering.

The reports gathered here are the strongest argument for reading disclosures rather than checklists. Each one is a case where a reviewer reconstructed the intended invariant, then found the input that violated it — and the write-ups usually show that reasoning explicitly.

Common shapes include edge cases at zero and at maximum, first and last participant conditions, and paths that behave differently when a step is skipped or repeated.

What reviewers look for

  • State machines with unreachable-looking transitions that are in fact reachable
  • Zero-value, single-participant and final-participant edge cases
  • Accounting that differs depending on the order of two independent calls
  • Emergency or pause paths that bypass invariant checks
  • Loops whose bounds depend on user-controlled length

Curated highlights

The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.

highLogic errorEVM-Solidity$120k

Rounding direction lets attacker mint shares for free on first deposit

A classic ERC-4626 share inflation vulnerability enabled an attacker to steal deposits from initial vault users. By depositing a single wei of assets to receive one share and then transferring a large amount of assets directly to the vault contract, the exchange rate ratio was severely skewed. Subsequent deposits from victims rounded down to zero minted shares while forfeiting their underlying tokens, allowing the attacker to redeem their single share for the entire vault balance.

ERC-4626 VaultcantinaJan 15, 2024Open
lowLogic errorEVM-Solidity$9k

Oracle-free AMM invariant rounding allows slow drain

A directional rounding flaw in the Newton-Raphson solver for a StableSwap invariant enabled subtle value extraction during token exchanges. When computing invariant values and target balances, both routines rounded down, yielding an extra wei of token output to the user on specific balance ratios. On low-fee Layer 2 blockchains, an automated script could execute high-frequency minimal swaps to steadily extract pool reserves over time.

Stableswap PoolhatsApr 9, 2024Open
highLogic errorOther$2k

Docker Secret Disclosure via GitHub Actions Cache Poisoning

A GitHub Actions cache poisoning vulnerability was identified in the Hyperledger repository infrastructure. The flaw allowed unauthorized actors to modify shared build cache keys and execute arbitrary code within CI/CD pipeline steps. When downstream workflows restored the manipulated cache, sensitive Docker credentials stored in environment variables were exposed. This allowed attackers to extract critical pipeline secrets without requiring write permissions to the underlying repository.

hyperledgerhackeroneApr 20, 2024Open
mediumLogic errorOther$100

Window.opener bug at www.coinbase.com

A web application link on www.coinbase.com opened external URLs using target="_blank" without setting the rel="noopener" or rel="noreferrer" security attributes. This allowed the newly opened destination window to access and manipulate the parent tab through the JavaScript window.opener reference. An attacker controlling the external target site could leverage this access to redirect the user's active Coinbase tab to a malicious external URL or phishing page. Coinbase rewarded the finding with a $100 bounty.

coinbasehackeroneNov 28, 2016Open
mediumLogic errorEVM-Solidity$0

Rigor Protocol: `updateProjectHash` does not check project address

Rigor Protocol's Project.sol has an asymmetry in its signature-verification paths: every external function except `updateProjectHash` binds the signed `_data` payload to the project contract via `require(_data.projectAddress == address(this))`, but L162 omits this binding. Because the signed message does not commit to the specific project, a `_data`/`_signature`/`_nonce` tuple produced by a shared builder or contractor for one project can be replayed on a different project once its nonce counter reaches the same value. In practice this lets an observer reuse an older task-hash update signature to change a task hash in a newly opened project that shares the same signer group, bypassing authorization. The Rigor developer confirmed the finding during the Code4rena contest.

Rigor Protocolcode4renaAug 7, 2026Open
mediumLogic errorEVM-Solidity$0

Rigor Protocol: `Project.addTasks()` wouldn't work properly when it's called from disputes contract.

A stale task-count consistency check in Rigor's Project.addTasks() causes task additions to revert when a dispute is pending. Because disputes take days to resolve while builders/contractors may legitimately add tasks in the interim, the project becomes unable to add new tasks (beyond the count snapshot at raiseDispute time) until the dispute is settled. The report proposes skipping the taskCount equality check when addTasks is invoked from the disputes contract, and the developer confirmed the issue.

Rigor Protocolcode4renaAug 7, 2026Open

All reports in this group

Chains where this class shows up

Related vulnerability category pages