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
- 102
- 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.
Yield Basis: The incorrect initialize of `specific_emissions_per_gauge` in `GaugeController::add_gauge()`
Yield Basis's GaugeController initializes a newly added gauge's per-gauge emission baseline from the controller's global specific_emissions value, which can be stale if the prior gauge checkpoint predates the addition. Because _checkpoint_gauge() skips the per-gauge bookkeeping when called in the same block as add_gauge() (the block.timestamp > t guard fails), the new gauge's baseline never advances past the older timestamp. On the next checkpoint the gauge is credited emission-weighted value for the entire stale window, letting it capture excess YB emissions it did not earn. The judge ruled this a medium-severity accounting flaw, and the fix is to initialize the new gauge with the current, updated specific_emissions.
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: 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: `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.
All reports in this group
- BendDAO: Changing auction duration will have effect on ongoing auctionsGovernance attack$0
- Olas: Adding staking instance as nominee before it is createdGovernance attack$0
- Olas: Less active nominees can be left without rewards after an year of inactivityGovernance attack$0
- Tapioca DAO: `MagnetarMintXChainModule.sol`:`mintBBLendXChainSGL` can be used to manipulate user positions by abusing whitelist privilegesGovernance attack$0
- Tapioca DAO: Gov (`twTAP`) and Tapioca Option can be monopolized by an attackerGovernance attack$0
- Tapioca DAO: `twAML` weights can be griefed by burning tokensGovernance attack$0
- Tapioca DAO: Max magnitude lock check will lead to a DoS and possible monopolization of `gov/Option` on `twTAP`/`TapiocaOptionBroker`Governance 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
- Canto: Improper adjustment of Lending Ledger configurationGovernance attack$0
- Salty.IO: Remove Liquidity has missing reserve1 DUST check, which can make reserve1 to be less than DUSTGovernance attack$0
- Salty.IO: StakingRewards pools are not given their promised share of rewards due to incorrect calculationGovernance attack$0
- Salty.IO: SALT staker can get extra voting power by simply unstaking their xSALTGovernance attack$0
- Salty.IO: Some rewards from POL will not be send to team wallet nor burnedGovernance 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: When forming POL the DAO will end up stucked with DAI and USDS tokens that cannot handleGovernance attack$0
- Salty.IO: Persistent Contract Call revert prevents finalizing a ballotGovernance attack$0
- Salty.IO: Ballots not yet past their deadline are incorrectly looped too by tokenWhitelistingBallotWithTheMostVotes()Governance attack$0
- Salty.IO: Caller of Upkeep may skip step 11 to save gasGovernance attack$0
- Salty.IO: changeWallets() can be confirmed immediately after proposalWallets() by manipulating activeTimelock beforehandGovernance attack$0
- Salty.IO: Impossible to change managed wallets with `proposeWallets` after first rejectionGovernance attack$0
- Mento: User Can Vote Even When They Have 0 Locked Mento (Edge Case)Governance attack$0
- Tapioca: mTOFTReceiver MSG_XCHAIN_LEND_XCHAIN_LOCK unable to executeGovernance 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: Anyone can prolong the time for the rewards to get distributedGovernance attack$0
- Ethereum Credit Guild: `SurplusGuildMinter.getReward()` is susceptible to DoS due to unbounded loopGovernance 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: ProfitManager's `creditMultiplier` calculation does not count undistributed rewards; this can cause value losses to usersGovernance attack$0
- Ethereum Credit Guild: `RateLimitedMinter` isn't used by `SimplePSM` resulting in Governance attacksGovernance attack$0
- Ethereum Credit Guild: Users can deflate other markets Guild holders rewards by staking less priced tokenGovernance attack$0
- Ethereum Credit Guild: The `userGaugeProfitIndex` is not set correctly, allowing an attacker to receive rewards without waitingGovernance 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
- Collective: It may be possible to DoS AuctionHouse by specifying malicious creatorsGovernance attack$0
- Collective: Bidder can use donations to get VerbsToken from auction that already endedGovernance 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
- Olympus On-Chain Governance: High risk checks can be bypassed with extra `calldata` paddingGovernance attack$0
- Olympus On-Chain Governance: Nobody can cast for any proposalGovernance attack$0
- PartyDAO: `PartyGovernanceNFT` advertises but does not honor the ERC-4906 standardGovernance attack$0
- PartyDAO: `PartyGovernanceNFT#rageQuit()` can lead to token loss for users when dealing with zero-balance ERC20 during a `rageQuit()`Governance attack$0
- PartyDAO: Single host can unfairly skip veto period for proposal that does not have full host supportGovernance attack$0
- PartyDAO: Some arbitrary proposal calls will fail because `executeProposal()` in `ProposalExecutionEngine` is not payableGovernance attack$0
- PartyDAO: `ETHCrowdfundBase.sol#processContribution` - Impossible to finalize crowdfund because of `minContribution` checkGovernance 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
- 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: Attacker can block LayerZero channel due to variable gas cost of saving payloadGovernance attack$0
- Tapioca DAO: User can give himself approval for all assets held by `MagnetarV2` contractGovernance 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: Ability to steal user funds and increase collateral share infinitely in BigBang and SingularityGovernance attack$0
- Tapioca DAO: Lack of safety buffer between liquidation threshold and LTV ratio for borrowers to prevent unfair liquidationsGovernance attack$0
- Tapioca DAO: Not enough TAP tokens to exercise if a user participates and exercises in the same epochGovernance 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: `BalancerStrategy.sol`: `_withdraw` withdraws insufficient tokensGovernance attack$0
- Tapioca DAO: TOFT leverageDown always fails if TOFT is a wrapper for native tokensGovernance attack$0
- Tapioca DAO: TOFT `exerciseOption` can be used to steal all underlying erc20 tokensGovernance attack$0
- Tapioca DAO: The BigBang contract take more fees than it shouldGovernance attack$0
- Tapioca DAO: TOFT and USDO Modules Can Be SelfdestructedGovernance attack$0
- Tapioca DAO: Collateral can be locked in BigBang contract when `debtStartPoint` is nonzeroGovernance attack$0
- Tapioca DAO: `BaseTOFTLeverageModule.sol`: `leverageDownInternal` tries to burn tokens from wrong addressGovernance attack$0
- Tapioca DAO: `exitPosition` in `TapiocaOptionBroker` may incorrectly inflate position weightsGovernance 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.sol`: Reward tokens stored in index 0 can be stolenGovernance attack$0
- Tapioca DAO: `SGLLiquidation::_computeAssetAmountToSolvency`, `Market::_isSolvent` and `Market::_computeMaxBorrowableAmount` may overestimate the collateral, resulting in false solvencyGovernance attack$0
- Tapioca DAO: Rewards compounded in AaveStrategy are unredeemableGovernance attack$0
- Tapioca DAO: Attacker can steal victim's oTAP position contents via `MagnetarMarketModule#_exitPositionAndRemoveCollateral()`Governance 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: Funds are locked because borrowFee is not correctly implemented in BigBangGovernance attack$0
- Tapioca DAO: Accounted balance of GlpStrategy does not match withdrawable balance, allowing for attackers to steal unclaimed rewardsGovernance attack$0
- Centrifuge: DelayedAdmin Cannot `PauseAdmin.removePauser`Governance attack$0
- Maia DAO Ecosystem: `updatePeriod()` has less minting of `HERMES`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: 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: `vMaia` is ERC-4626 compliant, but the `maxWithdraw` & `maxRedeem` functions are not fully up to EIP-4626's specificationGovernance attack$0
- Maia DAO Ecosystem: Unstaking `vMAIA` tokens on the first Tuesday of the month can be offsetGovernance attack$0
- Maia DAO Ecosystem: `UlyssesToken.setWeights(...)` can cause user loss of assets on vault deposits/withdrawalsGovernance 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: Many `create` methods are suspicious of the reorg attackGovernance attack$0
- Maia DAO Ecosystem: A user can bypass bandwidth limit by repeatedly "balancing" the poolGovernance attack$0
- Maia DAO Ecosystem: Deploy flow of `Talos` is brokenGovernance attack$0
- Maia DAO Ecosystem: Governance relies on the current `totalSupply` of `bHermes` when calculating `proposalThresholdAmount` and `quorumVotesAmount`Governance attack$0
- Maia DAO Ecosystem: `BaseV2Minter` DAO reward shares are calculated wrongGovernance attack$0
- Maia DAO Ecosystem: `VirtualAccount` cannot directly send native tokensGovernance 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: In `ERC20Boost.sol`, a user can be `attached` to a gauge and have no boost balance.Governance attack$0
- Maia DAO Ecosystem: Wrong consideration of `blockformation` period causes incorrect `votingPeriod` and `votingDelay` calculationsGovernance attack$0
- Maia DAO Ecosystem: `UlyssesPool.sol` does not match `EIP4626` because of the preview functionsGovernance 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
- Lybra Finance: `EUSD.mint` function wrong assumption of cases when calculated sharesAmount = 0Governance attack$0
- Lybra Finance: Wrong `proposalThreshold` amount in `LybraGovernance.sol`Governance 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
- Asymmetry Finance: Non-ideal rETH/WETH pool used pays unnecessary feesGovernance attack$0