# Borrowers can DoS liquidations by repaying as little as 1 share.

Borrower frontruns a liquidation by repaying 1 borrow share, shrinking max liquidable shares below the liquidator's specified amount and reverting the tx.

- Payout: Contest reward
- Severity: medium
- Program: Wise Lending
- Credited: 0xStalin
- Disclosed: 2024-05-03
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2024-02-wise-lending-findings/issues/237
- Library page: https://bugbountylibrary.com/r/c4%3A2024-02-wise-lending%3AM-08
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:race-window technique:source-review vuln:business-logic vuln:dos vuln:liquidation

**Target:** lending pool liquidation (WiseLending/WiseSecurityHelper)
**Root cause:** checkMaxShares reverts with TooManyShares when _shareAmountToPay exceeds 50% of current borrowShares; since maxShares is computed from live borrowShares, any tiny repayment before the liquidation lowers the cap and invalidates the liquidator's fixed amount.
**Steps:**
1. Position has 100 borrowShares on PoolA and is liquidable; liquidator submits liquidatePartiallyFromTokens with `_shareAmountToPay = 50` (the 50% max).
2. Borrower frontruns with `WiseLending.paybackExactShares()` repaying 1 share, leaving 99 borrowShares.
3. Liquidator tx executes; checkMaxShares computes maxShares = 99 * 50 / 1e18 = 49.5.
4. `_shareAmountToPay (50) > maxShares (49.5)` triggers `revert TooManyShares()`, liquidation fails.
**How found:** Code review of checkMaxShares: noticed maxShares is derived from live getPositionBorrowShares rather than a snapshot, and that the function reverts instead of clamping, making the liquidator's fixed share amount fragile to any state change.
**Exploitation:** Borrower monitors mempool for liquidation txs targeting their position and submits a minimal 1-share payback with higher gas to land first, repeatedly reverting liquidator attempts and stalling liquidation to avoid collateral seizure / accrue bad debt risk.
**Insight:** When a validation compares a caller-supplied amount against a live, attacker-mutable cap and reverts on excess, the borrower can nudge the cap by the smallest possible unit to invalidate the whole call; prefer clamping to maxShares over reverting.