Governance vulnerabilities in disclosed bug bounty reports
When voting power is cheap to rent and execution is fast to reach, governance is an attack surface with admin privileges attached.
- Reports indexed
- 90
- Total paid
- $350k
- Critical
- 0
- Largest payout
- $350k
Governance systems concentrate every privileged action behind one process, which makes flaws in that process equivalent to a compromise of the whole protocol. The findings split between acquiring voting power that should not be acquirable and executing a proposal that should not be executable.
On the acquisition side: voting weight counted at the current block instead of a snapshot, delegation that can be recycled within a transaction, and tokens that remain votable while deposited elsewhere. On the execution side: timelocks that can be bypassed through a queued call, proposal payloads that differ between the vote and the execution, and quorum computed against a supply the proposer can change.
Severity in this class is usually rated on what the successful proposal could reach, which is why so many of these reports are graded critical even where the exploit path is long.
What reviewers look for
- Voting power read at the current block rather than from a snapshot
- Delegation transferable within a single transaction
- Timelock bypasses through queued or nested calls
- Quorum measured against a supply the attacker can inflate
- Proposal payloads mutable between voting and execution
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Governance proposal executes arbitrary call via delegatecall module
A severe vulnerability in the governance timelock contract enabled proposal execution using DELEGATECALL without restricting the target address to a verified allowlist. Because the delegatecall target contract operated within the context of the timelock's storage without layout restrictions, a malicious proposal could overwrite key storage slots. An attacker leveraging flash loans or governance weight could pass a proposal that delegated to a custom contract, overwriting the timelock admin address in slot 0 to hijack governance authority and drain treasury funds.
Reserve: The default Governor Anastasius is unable to call `resetStakes`
In Reserve Protocol, executing a proposal through the default Governor Anastasius contract to call `resetStakes` permanently reverts. During execution, `resetStakes` increments the protocol's internal staking `era` variable. However, the governance contract checks that the proposal started in the current era *after* executing the call payload rather than before. As a result, the state change induced by `resetStakes` causes the trailing era validation check to fail, preventing governance from ever executing stake resets.
Reserve: Dutch auctions can fail to settle if any other collateral in the basket behaves unexpectedly
In Reserve Protocol's BackingManager, settlement of Dutch auctions attempts to chain directly into collateral rebalancing using a Solidity try-catch block. The implementation assumes that receiving empty error data inside the catch block exclusively signals an out-of-gas condition. However, external operations during rebalancing—such as interactions with upgradeable collateral tokens or calls to empty contract addresses—can also revert with empty error bytes. As a result, unexpected reverts from collateral assets cause auction settlements to fail entirely, preventing trades from clearing at fair market value.
BendDAO: `YieldEthStakingLido` lacks a limit on the max stake amount, which may result in the unstake exceeding `MAX_STETH_WITHDRAWAL_AMOUNT`, resulting in the token not being retrieved
The YieldEthStakingLido contract contains a logic flaw that prevents users from unstaking funds if their staked stETH balance exceeds Lido's 1,000 stETH limit per withdrawal request. Because the contract attempts to process the entire withdrawal amount in a single batch, any position exceeding this limit will cause the transaction to revert. This leads to a denial of service where user funds become locked within the YieldEthStakingLido contract with no mechanism to recover them.
BendDAO: Bad debt is never handled which places insolvency risks on BendDAO
BendDAO's current lending architecture lacks a formal mechanism for managing bad debt, creating significant solvency risk during market crashes. When the value of collateral falls below the borrowed debt, the protocol's liquidation logic fails to clear the outstanding balance, either because it cannot handle remaining debt after collateral exhaustion or because the liquidation is not economically profitable. This failure effectively traps liquidity within the protocol, preventing depositors from withdrawing their funds and resulting in an indefinite denial of service during insolvency events.
BendDAO: Changing auction duration will have effect on ongoing auctions
The protocol incorrectly calculates auction expiration times by dynamically adding a configurable duration parameter to a loan's start timestamp. Consequently, if the protocol administrator updates the auction duration, it retroactively affects all auctions currently in progress. This can lead to unexpected premature auction closures, potentially preventing borrowers from redeeming their debt or causing liquidators to settle auctions earlier than participants anticipated.
All reports in this group
- Olas: Less active nominees can be left without rewards after an year of inactivityGovernance attack$0
- Olas: Adding staking instance as nominee before it is createdGovernance attack$0
- Taiko: The top tier prover can not re-proveGovernance attack$0
- Taiko: Taiko L1 - Proposer can maliciously cause loss of funds by forcing someone else to pay prover's feeGovernance attack$0
- Salty.IO: StakingRewards pools are not given their promised share of rewards due to incorrect calculationGovernance attack$0
- Salty.IO: When forming POL the DAO will end up stucked with DAI and USDS tokens that cannot handleGovernance attack$0
- Salty.IO: Ballots not yet past their deadline are incorrectly looped too by tokenWhitelistingBallotWithTheMostVotes()Governance attack$0
- Salty.IO: Persistent Contract Call revert prevents finalizing a ballotGovernance attack$0
- Salty.IO: Remove Liquidity has missing reserve1 DUST check, which can make reserve1 to be less than DUSTGovernance attack$0
- Salty.IO: Unwhitelisting does not clear _arbitrageProfits, so re-whitelisting may result in an unfair distribution of liquidity rewardsGovernance attack$0
- Salty.IO: Impossible to change managed wallets with `proposeWallets` after first rejectionGovernance attack$0
- Salty.IO: Some rewards from POL will not be send to team wallet nor burnedGovernance attack$0
- Salty.IO: changeWallets() can be confirmed immediately after proposalWallets() by manipulating activeTimelock beforehandGovernance attack$0
- Salty.IO: Caller of Upkeep may skip step 11 to save gasGovernance attack$0
- Ethereum Credit Guild: Re-triggering the `canOffboard[term]` flag to bypass the DAO vote of the lending term offboarding mechanismGovernance attack$0
- Ethereum Credit Guild: Anyone can prolong the time for the rewards to get distributedGovernance attack$0
- Ethereum Credit Guild: Users can deflate other markets Guild holders rewards by staking less priced tokenGovernance attack$0
- Ethereum Credit Guild: `RateLimitedMinter` isn't used by `SimplePSM` resulting in Governance attacksGovernance attack$0
- Ethereum Credit Guild: There is no way to liquidate a position if it breaches `maxDebtPerCollateralToken` value creating bad debt.Governance attack$0
- Ethereum Credit Guild: The creation of bad debt (`mark-down` of Credit) can force other loans in auction to also create bad debtGovernance attack$0
- Ethereum Credit Guild: `SurplusGuildMinter.getReward()` is susceptible to DoS due to unbounded loopGovernance attack$0
- Ethereum Credit Guild: ProfitManager's `creditMultiplier` calculation does not count undistributed rewards; this can cause value losses to usersGovernance attack$0
- Ethereum Credit Guild: The `userGaugeProfitIndex` is not set correctly, allowing an attacker to receive rewards without waitingGovernance attack$0
- Collective: Bidder can use donations to get VerbsToken from auction that already endedGovernance attack$0
- Collective: `ArtPiece.totalVotesSupply` and `ArtPiece.quorumVotes` are incorrectly calculated due to inclusion of the inaccessible voting powers of the NFT that is being auctioned at the moment when an art piece is createdGovernance attack$0
- Olas: Bonds created in year cross epoch's can lead to lost payoutsGovernance attack$0
- Particle Protocol: Modifying the loan term setting can default existing loansGovernance attack$0
- PartyDAO: Some arbitrary proposal calls will fail because `executeProposal()` in `ProposalExecutionEngine` is not payableGovernance attack$0
- PartyDAO: `PartyGovernanceNFT` advertises but does not honor the ERC-4906 standardGovernance attack$0
- PartyDAO: `PartyGovernance.sol#accept` - `passThresholdBps` isn't cached for each proposal which can lead to problems if changed through another proposalGovernance attack$0
- PartyDAO: `ETHCrowdfundBase.sol#processContribution` - Impossible to finalize crowdfund because of `minContribution` checkGovernance attack$0
- PartyDAO: Single host can unfairly skip veto period for proposal that does not have full host supportGovernance attack$0
- PartyDAO: `PartyGovernanceNFT#rageQuit()` can lead to token loss for users when dealing with zero-balance ERC20 during a `rageQuit()`Governance attack$0
- Open Dollar: Due to extremely short `votingDelay` and `votingPeriod`, governance is practically impossibleGovernance attack$0
- Maia DAO: The governance will fail to add an ecosystem token if someone creates a hToken that uses that ecosystem tokenGovernance attack$0
- Tapioca DAO: TOFT `exerciseOption` can be used to steal all underlying erc20 tokensGovernance attack$0
- Tapioca DAO: Ability to steal user funds and increase collateral share infinitely in BigBang and SingularityGovernance attack$0
- Tapioca DAO: Not enough TAP tokens to exercise if a user participates and exercises in the same epochGovernance attack$0
- Tapioca DAO: triggerSendFrom() will send all the ETH in the destination chain where sendFrom() is called to the refundAddress in the LzCallParams argumentGovernance attack$0
- Tapioca DAO: `SGLLiquidation::_computeAssetAmountToSolvency`, `Market::_isSolvent` and `Market::_computeMaxBorrowableAmount` may overestimate the collateral, resulting in false solvencyGovernance attack$0
- Tapioca DAO: Collateral can be locked in BigBang contract when `debtStartPoint` is nonzeroGovernance attack$0
- Tapioca DAO: Exercise option cross chain message in the (m)TapiocaOFT will always revert in the destination, losing debited funds in the source chainGovernance attack$0
- Tapioca DAO: `_liquidateUser()` should not re-use the same minimum swap amount out for multiple liquidationGovernance attack$0
- Tapioca DAO: Attacker can block LayerZero channel due to variable gas cost of saving payloadGovernance attack$0
- Tapioca DAO: `BaseTOFTLeverageModule.sol`: `leverageDownInternal` tries to burn tokens from wrong addressGovernance attack$0
- Tapioca DAO: User can give himself approval for all assets held by `MagnetarV2` contractGovernance attack$0
- Tapioca DAO: TOFT and USDO Modules Can Be SelfdestructedGovernance attack$0
- Tapioca DAO: Attacker can steal victim's oTAP position contents via `MagnetarMarketModule#_exitPositionAndRemoveCollateral()`Governance attack$0
- Tapioca DAO: Rewards compounded in AaveStrategy are unredeemableGovernance attack$0
- Tapioca DAO: Accounted balance of GlpStrategy does not match withdrawable balance, allowing for attackers to steal unclaimed rewardsGovernance attack$0
- Tapioca DAO: `exitPosition` in `TapiocaOptionBroker` may incorrectly inflate position weightsGovernance attack$0
- Tapioca DAO: Funds are locked because borrowFee is not correctly implemented in BigBangGovernance attack$0
- Tapioca DAO: A user with a TapiocaOFT allowance >0 could steal all the underlying ERC20 tokens of the ownerGovernance attack$0
- Tapioca DAO: twTAP.claimAndSendRewards() will claim the wrong amount for each reward token due to the use of wrong indexGovernance attack$0
- Tapioca DAO: TOFT leverageDown always fails if TOFT is a wrapper for native tokensGovernance attack$0
- Tapioca DAO: `twTAP.sol`: Reward tokens stored in index 0 can be stolenGovernance attack$0
- Tapioca DAO: `BalancerStrategy.sol`: `_withdraw` withdraws insufficient tokensGovernance attack$0
- Tapioca DAO: Lack of safety buffer between liquidation threshold and LTV ratio for borrowers to prevent unfair liquidationsGovernance attack$0
- Tapioca DAO: The BigBang contract take more fees than it shouldGovernance attack$0
- Centrifuge: DelayedAdmin Cannot `PauseAdmin.removePauser`Governance attack$0
- Maia DAO Ecosystem: `vMaia` is ERC-4626 compliant, but the `maxWithdraw` & `maxRedeem` functions are not fully up to EIP-4626's specificationGovernance attack$0
- Maia DAO Ecosystem: In `ERC20Boost.sol`, a user can be `attached` to a gauge and have no boost balance.Governance attack$0
- Maia DAO Ecosystem: Re-adding a deprecated gauge in a new epoch before calling `updatePeriod()`/`queueRewardsForCycle()` will leave some gauges without rewardsGovernance attack$0
- Maia DAO Ecosystem: A user can bypass bandwidth limit by repeatedly "balancing" the poolGovernance attack$0
- Maia DAO Ecosystem: `BaseV2Minter` DAO reward shares are calculated wrongGovernance attack$0
- Maia DAO Ecosystem: `updatePeriod()` has less minting of `HERMES`Governance attack$0
- Maia DAO Ecosystem: Many `create` methods are suspicious of the reorg attackGovernance attack$0
- Maia DAO Ecosystem: Although `ERC20Boost.decrementGaugesBoostIndexed` function would require the user to remove all of their boosts from a deprecated gauge at once, such a user can instead call `ERC20Boost.decrementGaugeBoost` function multiple times to utiliz…Governance attack$0
- Maia DAO Ecosystem: Wrong consideration of `blockformation` period causes incorrect `votingPeriod` and `votingDelay` calculationsGovernance attack$0
- Maia DAO Ecosystem: Claiming outstanding utility tokens from `vMaia` vault DoS on `pbHermes<>bHermes` conversion rate `>` 1Governance attack$0
- Maia DAO Ecosystem: Removing a `UniswapV3Gauge` via `UniswapV3GaugeFactory` does not actually remove it from the `UniswapV3Staker`. The gauge still gains rewards and can be staked too (even though deprecated). Plus old stakers can game the rewards of new stake…Governance attack$0
- Maia DAO Ecosystem: `ERC4626PartnerManager.checkTransfer` does not check `amount` correctly, as it applies `bHermesRate` to `balanceOf[from]`, but not `amount`.Governance attack$0
- Maia DAO Ecosystem: Unstaking `vMAIA` tokens on the first Tuesday of the month can be offsetGovernance attack$0
- Maia DAO Ecosystem: Governance relies on the current `totalSupply` of `bHermes` when calculating `proposalThresholdAmount` and `quorumVotesAmount`Governance attack$0
- Maia DAO Ecosystem: `UlyssesPool.sol` does not match `EIP4626` because of the preview functionsGovernance attack$0
- Maia DAO Ecosystem: `UlyssesToken.setWeights(...)` can cause user loss of assets on vault deposits/withdrawalsGovernance attack$0
- Maia DAO Ecosystem: `VirtualAccount` cannot directly send native tokensGovernance attack$0
- Maia DAO Ecosystem: Deploy flow of `Talos` is brokenGovernance attack$0
- Lybra Finance: Wrong `proposalThreshold` amount in `LybraGovernance.sol`Governance attack$0
- Lybra Finance: `EUSD.mint` function wrong assumption of cases when calculated sharesAmount = 0Governance attack$0
- Lybra Finance: Governance wrongly calculates `_quorumReached()`Governance attack$0
- Lybra Finance: Allowing `refreshReward()` to fail during minting or buring esLBR could result in gain or loss previously earned rewardGovernance attack$0
- Asymmetry Finance: Non-ideal rETH/WETH pool used pays unnecessary feesGovernance attack$0
- Asymmetry Finance: In de-peg scenario, forcing full exit from every derivative & immediately re-entering can cause big losses for depositorsGovernance attack$0