# Lack of access control on assertGovernanceApproved can cause funds to be locked

Missing access control on FlashGovernanceArbiter.assertGovernanceApproved lets anyone pull a victim's approved tokens via transferFrom and lock them for the unlock period.

- Payout: Audit contest
- Severity: high
- Program: Behodler
- Found by: shw
- Disclosed: 2022-03-24
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-01-behodler-findings/issues/300
- Library page: https://bugbountylibrary.com/r/c4%3A2022-01-behodler%3AH-01
- Tags: area:web3 domain:web3 impact:dos impact:funds-loss kind:contest platform:code4rena sev:high tech:evm tech:solidity technique:source-review vuln:access-control vuln:business-logic

**Target:** FlashGovernanceArbiter governance contract (Solidity/EVM)
**Root cause:** assertGovernanceApproved is callable by anyone and performs a transferFrom using an attacker-supplied `sender`/`from` address, so any approved allowance can be pulled and locked without the owner's consent.
**Steps:**
1. Alice calls `approve` on `flashGovernanceConfig.asset` granting FlashGovernanceArbiter allowance of `flashGovernanceConfig.amount`.
2. Bob front-runs by calling `assertGovernanceApproved(sender=Alice, target=anyAddress, emergency=true)`.
3. Contract executes transferFrom(Alice, ...) pulling her approved tokens and locking them for `flashGovernanceConfig.unlockTime`.
4. Alice cannot execute her flash governance decision and must wait out the unlock period to withdraw.
**How found:** Code review of FlashGovernanceArbiter noticed assertGovernanceApproved lacked access control and used a caller-supplied `from` in transferFrom, enabling griefing via existing allowances.
**Exploitation:** Attacker monitors mempool for victim approve transactions, front-runs with assertGovernanceApproved using victim as `sender` and emergency=true, forcing transferFrom of the approved amount into the contract where it is locked until unlockTime. Repeatable against all users who approved.
**Escalation:** Can be applied at once to all users who have granted allowance, locking aggregate funds protocol-wide.
**Insight:** Any transferFrom where `from` is a function argument rather than msg.sender is a griefing/theft vector: an attacker can consume any standing allowance. Grep for transferFrom with user-supplied from addresses in governance/escrow contracts.