# An attacker can preemptively block the configuration of boost values or the liquidation pair in VaultBooster through front-running

Attacker front-runs owner's setBoost by liquidating 1 wei of boost tokens, dropping balance below _initialAvailable and reverting the config update.

- Payout: Contest reward
- Severity: medium
- Program: PoolTogether
- Credited: 3agle
- Disclosed: 2023-09-07
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2023-08-pooltogether-findings/issues/60
- Library page: https://bugbountylibrary.com/r/c4%3A2023-08-pooltogether%3AM-08
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:source-review vuln:business-logic vuln:race-condition

**Target:** VaultBooster.setBoost / LiquidationPair.liquidate
**Root cause:** setBoost requires _initialAvailable <= current token balance; any liquidation between owner's tx submission and execution reduces balance, causing revert.
**Steps:**
1. Deploy VaultBooster with boost token balance and configured liquidation pair
2. Owner submits setBoost(boostToken, pair, multiplier, tokensPerSecond, initialAvailable=balance)
3. Attacker front-runs: mint/send minimal prize tokens to PrizePool and call `booster.liquidate(attacker, prizeToken, 100, boostToken, 100)` via LiquidationPair
4. Balance drops below _initialAvailable; owner's setBoost reverts with InitialAvailableExceedsBalance
**How found:** Code reading of setBoost's balance check against _initialAvailable; recognized that liquidate() mutates the same balance, enabling a griefing front-run.
**Exploitation:** Attacker monitors mempool for owner's setBoost tx, submits a liquidation of as little as 1 wei in the same block ahead of it, forcing revert and indefinitely blocking parameter updates.
**Insight:** When a config setter validates against a live, externally-mutable balance, an attacker can move that balance to force reverts—look for setters that compare inputs to on-chain state an unprivileged actor can change.