# User specified slippage allows frontrunning

PerpDepository.rebalance accepts arbitrary account and user-set slippage, letting a frontrunner sandwich the Uniswap swap and drain approved funds.

- Payout: Contest reward
- Severity: high
- Program: Uxd
- Credited: zeroknots
- Disclosed: 2022-12-27
- Write-up quality: 7/10
- Original: https://github.com/sherlock-audit/2023-01-uxd-judging/issues/192
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-01-uxd%3AH-6
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:high tech:evm tech:solidity technique:race-window technique:source-review vuln:access-control vuln:business-logic

**Target:** PerpDepository.rebalance / rebalanceLite on-chain contract
**Root cause:** rebalance/rebalanceLite pull funds from a caller-supplied `account` (not msg.sender) and honor a caller-supplied `amountOutMinimum`, so any address with an approval can be drained via a zero-slippage swap.
**Steps:**
1. Victim approves PerpDepository for token funds.
2. Victim submits `rebalance(account, ..., amountOutMinimum=X)`; attacker observes it in mempool.
3. Attacker resubmits same call with higher gas and `amountOutMinimum=0`.
4. Attacker front-runs the Uniswap swap (buy before, sell after) to sandwich the now-unprotected swap.
5. Attacker profits; victim's account loses value.
**How found:** Code review noting rebalance takes `account` as an argument rather than msg.sender, combined with a caller-controlled slippage parameter, enabling third-party frontrunning of any approved account.
**Exploitation:** Mempool monitoring of rebalance calls; duplicate tx with raised gas and amountOutMinimum=0; sandwich the Uniswap pool swap to extract the slippage difference from the victim's approved funds.
**Insight:** When a function pulls funds from a caller-supplied address instead of msg.sender, any approval becomes spendable by anyone; check whether slippage/limit params are also caller-controlled, since that turns a griefing primitive into a profitable sandwich.