critical

Governance Attack: How It Works, Real Exploits & Automated Detection

April 1, 2026
Chainsethereumarbitrumbaseoptimismpolygon
Detected byslithermythrilechidnahound-ai

Governance attacks exploit flaws in voting and proposal mechanisms, allowing attackers to seize control of DAOs and protocols. Beanstalk ($182M, 2022) and Lido's near-attack demonstrated that governance vulnerabilities can drain entire treasuries. Attacks range from flash loan voting to voting weight issues to unguarded proposal execution. Firepan's HOUND AI detects governance vulnerabilities automatically during development and post-deployment monitoring, covering continuous analysis across the full contract lifecycle.

What Is Governance Attack?

Governance attacks exploit protocols' decision-making mechanisms to execute unauthorized actions, steal treasury funds, or change critical parameters. Common attack vectors:

  1. Flash loan voting: Attacker borrows tokens, votes, returns tokens in same transaction
  2. Voting weight snapshot issues: Voting power determined by current balance (flashable)
  3. Unguarded proposal execution: Anyone can execute passed proposals
  4. Quorum bypass: Quorum not properly validated
  5. Delegation bypasses: Vote delegation vulnerable to replay or front-running
  6. Timelock bypass: Emergency pause functions unguarded
  7. Parameter manipulation: Critical parameters changeable by proposals without limits

The vulnerability is critical because:

  • Complete control: Governance controls all protocol parameters
  • Treasury access: Can drain entire treasury via governance proposal
  • Irreversible: Governance changes cannot be quickly reverted
  • Trusted mechanism: Users believe governance is secure; attacks are unexpected

How Governance Attack Works

Governance attacks follow a pattern:

  1. Identify vulnerability: Find flash loan voting, unguarded execution, or quorum bypass
  2. Calculate attack cost: Determine capital needed (flash loan + gas costs)
  3. Craft proposal: Create proposal to steal treasury or change parameters
  4. Execute attack: Use flash loan to vote, execute proposal, drain treasury
  5. Profit: Extract treasury funds or gain control
// VULNERABLE — example only
// Demonstrates: Governance Attack
// Do NOT use in production

pragma solidity ^0.8.0;

contract VulnerableGovernance {
    address public gov;
    mapping(address => uint256) public balance;
    mapping(uint256 => Proposal) public proposals;
    uint256 public proposalCount;

    struct Proposal {
        address target;
        bytes data;
        uint256 votesFor;
        uint256 votesAgainst;
        bool executed;
        uint256 deadline;
    }

    // VULNERABLE: Voting power from current balance (flashable)
    function vote(uint256 proposalId, bool support) public {
        // VULNERABLE: Uses current balance, which can be flash loaned!
        uint256 votingPower = balance[msg.sender];

        if (support) {
            proposals[proposalId].votesFor += votingPower;
        } else {
            proposals[proposalId].votesAgainst += votingPower;
        }
    }

    // VULNERABLE: No access control on execution
    function executeProposal(uint256 proposalId) public {
        Proposal storage prop = proposals[proposalId];
        require(!prop.executed);
        require(block.timestamp > prop.deadline);
        require(prop.votesFor > prop.votesAgainst);

        // VULNERABLE: Anyone can execute!
        prop.executed = true;
        (bool success, ) = prop.target.call(prop.data);
        require(success);
    }

    // VULNERABLE: No quorum check
    function propose(address target, bytes memory data) public {
        require(balance[msg.sender] > 0);

        proposals[proposalCount] = Proposal({
            target: target,
            data: data,
            votesFor: 0,
            votesAgainst: 0,
            executed: false,
            deadline: block.timestamp + 7 days
        });

        proposalCount++;
    }
}

contract GovernanceAttacker {
    VulnerableGovernance public gov;
    address public flashLoanProvider;
    address public govToken;

    function attackViaFlashLoan() public {
        // STEP 1: Borrow governance token via flash loan
        IFlashLoanProvider(flashLoanProvider).flashLoan(
            address(this),
            govToken,
            1000000 ether,  // Borrow huge amount
            abi.encodeWithSignature("_executeAttack()")
        );
    }

    function _executeAttack() internal {
        // STEP 2: With borrowed tokens, vote on proposal
        // Create proposal: transfer entire treasury to attacker
        gov.propose(
            address(gov),
            abi.encodeWithSignature("stealTreasury(address)", address(this))
        );

        // STEP 3: Vote with borrowed tokens
        gov.vote(gov.proposalCount() - 1, true);

        // STEP 4: Wait for deadline, execute proposal
        // (In flash loan attack, attacker prepares second transaction to execute after 7 days)

        // STEP 5: Repay flash loan
        IERC20(govToken).approve(flashLoanProvider, borrowed + fee);
    }
}

contract QuorumBypassAttack {
    VulnerableGovernance public gov;

    function attackQuorum() public {
        // Proposal might require quorum, but vote() doesn't check it
        // Attacker creates proposal, votes with minimal balance
        // Votes > quorum without actually meeting quorum requirement

        gov.propose(address(0), "");  // Create proposal
        gov.vote(0, true);  // Vote with attacker's balance
        gov.executeProposal(0);  // Execute without proper quorum
    }
}

Real-World Governance Exploits

| Protocol | Date | Loss | Root Cause | |----------|------|------|-----------| | Beanstalk | 2022-04 | $182M | Flash loan voting to pass malicious proposal | | Lido (near-miss) | 2021 | $10B+ at risk | Governance attack prevented last-minute | | Curve DAO | 2020-2023 | $5M+ | Governance parameter manipulation | | Compound (near-miss) | 2020 | $150M+ at risk | cToken voting weight bugs |

How to Detect Governance Attack

Manual detection requires voting mechanism review:

  • Voting power source: Verify voting power comes from snapshot, not current balance
  • Vote snapshot timing: Confirm snapshot taken before voting begins
  • Quorum validation: Verify quorum is properly checked
  • Proposal execution: Confirm only authorized addresses can execute proposals
  • Timelock protection: Verify sufficient delay between proposal and execution
  • Vote delegation: Validate delegation logic against replay/front-running
  • Emergency functions: Confirm emergency pause functions have proper guards

Red flags:

  • Voting power based on current balance (flashable)
  • No block number snapshot for voting power
  • No quorum requirement
  • Anyone can execute passed proposals
  • No timelock between vote and execution
  • Delegation without nonce or replay protection
  • Emergency pause without governance approval

How Firepan Detects Governance Attack Automatically

Firepan's HOUND AI performs voting mechanism analysis:

  1. Voting mechanism mapping: Identifies vote(), propose(), execute() functions
  2. Vote source analysis: Traces where voting power originates
  3. Snapshot validation: Confirms voting power snapshotted at fixed block
  4. Quorum verification: Checks if quorum is required and enforced
  5. Access control verification: Confirms execute() has proper authorization
  6. Flash loan attack path finding: Constructs voting attack scenarios
  7. Timelock validation: Verifies execution delay between proposal and execution

Firepan's HOUND AI engine identifies governance vulnerabilities across all monitored contracts.

Prevention Best Practices

1. Use Block Number Snapshot for Voting Power

Never use current balance; always snapshot at specific block:

mapping(address => mapping(uint256 => uint256)) public balanceAtBlock;  // block → balance

function vote(uint256 proposalId, bool support) public {
    Proposal memory prop = proposals[proposalId];

    // Use balance at proposal block, not current balance
    uint256 votingPower = balanceAtBlock[msg.sender][prop.snapshotBlock];

    if (support) {
        prop.votesFor += votingPower;
    } else {
        prop.votesAgainst += votingPower;
    }
}

2. Implement Quorum Requirement

Require minimum participation for proposal passage:

uint256 public quorum = 40;  // 40% of tokens must participate

function executeProposal(uint256 proposalId) public {
    Proposal memory prop = proposals[proposalId];

    uint256 totalVotes = prop.votesFor + prop.votesAgainst;
    uint256 requiredVotes = (totalSupply * quorum) / 100;

    require(totalVotes >= requiredVotes, "Quorum not met");
    require(prop.votesFor > prop.votesAgainst);

    // Execute proposal...
}

3. Use Timelock for Execution

Delay execution after proposal passes to allow emergency pause:

import "@openzeppelin/contracts/governance/TimelockController.sol";

contract GovernanceWithTimelock {
    TimelockController timelock;

    function execute(uint256 proposalId) public {
        require(block.timestamp >= proposals[proposalId].delayedUntil);
        // Execute with delay protection
    }
}

4. Restrict Proposal Execution

Only allow governance or authorized addresses to execute:

function executeProposal(uint256 proposalId) public onlyGovernance {
    Proposal storage prop = proposals[proposalId];
    require(prop.votesFor > prop.votesAgainst);

    prop.executed = true;
    (bool success, ) = prop.target.call(prop.data);
    require(success);
}

5. Use OpenZeppelin Governor

Implement battle-tested governance contract:

import "@openzeppelin/contracts/governance/Governor.sol";

contract MyGovernor is Governor {
    constructor(IVotes _token)
        Governor("MyDAO")
        GovernorSettings(
            1,  // voting delay
            50400,  // voting period (1 week)
            100000e18  // proposal threshold
        )
    {}
}

Frequently Asked Questions

Q: What is governance attack in smart contracts?

A: Governance attack exploits voting flaws to seize control of DAOs, passing malicious proposals to steal treasury or change parameters. Flash loan voting is most common, where attackers borrow tokens, vote, and return tokens in same transaction.


Q: Which protocols have been exploited via governance?

A: Beanstalk ($182M, 2022) suffered flash loan governance attack. Lido and Compound faced critical vulnerabilities. Curve DAO governance parameters have been manipulated. Aggregate governance attack risk exceeds $20B+ across major DAOs.


Q: How does Firepan detect governance attack?

A: Firepan analyzes voting mechanisms, confirms snapshot blocks are used (not current balance), verifies quorum enforcement, checks execute() access control, identifies flash loan attack paths, and validates timelock delays.


Q: Can governance attacks be exploited after deployment?

A: Yes, governance vulnerabilities are immediately exploitable post-deployment. If flash loan voting is possible, attacker can drain treasury within one transaction. Beanstalk was exploited within hours of vulnerability.


Q: How do I prevent governance attacks?

A: Use block number snapshots for voting power (not current balance). Implement quorum requirement. Use timelock delay before execution. Restrict proposal execution to governance contract. Use OpenZeppelin Governor contract.

Conclusion

Governance attacks have cost DAOs $200M+, with potential risk exceeding $20B. Beanstalk's $182M loss demonstrated the severity. Modern governance uses block snapshots, quorums, and timelocks to eliminate flash loan voting. OpenZeppelin's Governor contract implements best practices. Firepan's HOUND AI detects governance vulnerabilities across all monitored contracts.

Start securing your smart contracts at https://app.firepan.com/

Firepan

Scan Your Contracts Now

12,453 contracts secured. 2,851 vulnerabilities blocked. 236 exploits prevented. Run a free surface scan — results in minutes, no credit card required.

Run Free Scan →