# Users can use updateBoost function to claim unfairly large rewards from liquidity mining contracts for themselves at cost of other users.

updateBoost retroactively applies a new boost multiplier to a user's entire past stake, letting them claim inflated liquidity-mining rewards at others' expense.

- Payout: Audit contest
- Severity: medium
- Program: Mimo DeFi
- Found by: smiling_heretic
- Disclosed: 2022-07-18
- Write-up quality: 7/10
- Original: https://github.com/code-423n4/2022-04-mimo-findings/issues/136
- Library page: https://bugbountylibrary.com/r/c4%3A2022-04-mimo%3AM-02
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:business-logic vuln:reward-distribution

**Target:** Liquidity mining contracts (SupplyMinerV2, DemandMinerV2, PARMinerV2, VotingMinerV2)
**Root cause:** updateBoost changes a user's boostMultiplier without first settling rewards and updating _userInfo.accAmountPerShare, so the new multiplier is applied to the whole historical stake.
**Steps:**
1. Alice and Bob each deposit 1 WETH and borrow 100 PAR in coreVaults with no locked veMIMO.
2. Wait a month while SupplyMinerV2 accrues 100 MIMO; fair split is 50/50.
3. Alice locks large veMIMO in votingEscrow so her boostMultiplier becomes 4.
4. Alice calls `supplyMiner.updateBoost(alice)` before repaying.
5. Alice claims 80 MIMO, leaving Bob 20.
6. Variant: Alice calls `supplyMiner.updateBoost(bob)` before Bob's `vaultsCore.repay()` to reset Bob's multiplier to 1 and claim 500 of 1000 MIMO.
**How found:** Code review of updateBoost vs releaseRewards: noticed boost can be updated without settling accAmountPerShare, so the multiplier applies to past stake.
**Exploitation:** Attacker locks veMIMO to raise their multiplier (or front-runs a victim's repay to lower the victim's multiplier), calls updateBoost to retroactively apply it to the entire unclaimed accrual period, then claims rewards, diluting honest users' share.
**Insight:** In reward-accrual contracts, any setter that changes a weight/multiplier must checkpoint rewards first; look for boost/weight update paths that skip accAmountPerShare settlement and test retroactive application over long unclaimed periods.