# Attackers can maliciously inflate total_supply temporarily to exceed utilization rate limit and push the pool towards 100% util rate, potentially causing a loss of lender funds

Blend's borrow util-rate check runs per-action, so a supply→borrow→withdraw batch temporarily inflates total_supply to bypass max_util and borrow past the limit.

- Payout: Contest reward
- Severity: medium
- Program: Blend
- Credited: rscodes
- Disclosed: 2025-08-13
- Write-up quality: 7/10
- Original: https://code4rena.com/reports/2025-02-blend-v2-audit-certora-formal-verification#m-14
- Library page: https://bugbountylibrary.com/r/c4%3A2025-02-blend-v2-audit-certora-formal-verification%3AM-14
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:solidity technique:chained vuln:accounting-error vuln:business-logic vuln:liquidation

**Target:** Soroban lending pool contract (actions.rs build_actions_from_request)
**Root cause:** require_utilization_below_max is only enforced inside apply_borrow, computed as total_liabilities/total_supply at that instant; a preceding apply_supply in the same batch inflates total_supply, and a following apply_withdraw removes it, so the final state exceeds max_util.
**Steps:**
1. Set reserve max_util=0.9, b_supply=100, d_supply=89 (already near limit).
2. Build a single request batch: `Supply 10.1234567`, `Borrow 2.0`, `Withdraw 10.1234567` on the same underlying.
3. apply_supply raises total_supply so borrow's util check passes; apply_withdraw nets off the supply (funds pulled at end, so attacker needs no capital).
4. Final state: loan outstanding with pool util pushed past max_util toward 100%.
5. Run modified sponsor test `test_build_actions_from_request_borrow_errors_over_max_util` with `#[should_panic]` removed; it passes.
**How found:** Read apply_borrow and noticed util check is per-action rather than at submit validation; hypothesized that ordering supply before borrow and withdraw after would temporarily inflate total_supply, then confirmed by editing the sponsor's existing should_panic test.
**Exploitation:** Attacker with existing collateral submits one execute_submit batch of supply+borrow+withdraw; the supply is netted off at settlement so no capital is required, yet the borrow persists at an illegal utilization level.
**Escalation:** Repeat during volatile markets to push pool to 100% util, maximizing bad-debt exposure for lenders.
**Insight:** When a risk invariant (utilization, LTV, cap) is checked inside a single action rather than at batch/submit validation, look for multi-action batches where a temporary state change (supply, deposit, mint) satisfies the check and a later action reverses it before settlement.