# Fee miscalculation and DoS via arbitrary owner parameter in ERC4626 redemption hooks

ERC4626 redemption hooks use the caller account instead of the user-supplied owner for cost-basis accounting, causing fee miscalculation or division-by-zero DoS.

- Payout: Contest reward
- Severity: medium
- Program: Superform
- Credited: 0xAlix2
- Disclosed: 2025-07-17
- Write-up quality: 6/10
- Original: https://cdn.cantina.xyz/reports/cantina_competition_superform_may2025.pdf#3.2.8
- Library page: https://bugbountylibrary.com/r/cantina%3Asuperform_may2025%3A3.2.8
- Tags: domain:web3 impact:dos impact:integrity kind:contest platform:cantina sev:medium tech:evm tech:solidity technique:source-review vuln:business-logic vuln:dos vuln:fee-bypass

**Target:** ApproveAndRedeem4626VaultHook / Redeem4626VaultHook ERC4626 redemption hooks
**Root cause:** _preExecute/_postExecute read share balances of the caller `account` rather than the user-specified `owner`, so usedShares is attributed to the wrong accumulator; if account holds no shares, calculateCostBasisView divides by zero.
**Steps:**
1. Deploy SuperLedger with ERC4626 yield source oracle, feePercent 1000.
2. User deposits 100e6 USDC into MockERC4626 and approves accountETH for max.
3. Build hooksData encoding yieldSourceOracleId, vault, asset, owner=user, shares=balanceOf(user), false.
4. Execute op via SuperExecutor with ApproveAndRedeem4626VaultHook; account has no shares so calculateCostBasisView reverts (division by zero).
5. Alternatively, account with some shares but != owner misattributes usersAccumulatorShares/CostBasis, producing wrong fee.
**How found:** Code review of _preExecute/_postExecute noticing `account` used for balance reads while `owner` is user-controlled in redeem callData, then tracing into calculateCostBasisView.
**Exploitation:** Attacker triggers redemption through hook with owner differing from account; either DoS via revert on zero-share account or under/over-charged fees by misattributing cost basis.
**Insight:** In hook-based accounting, verify that every balance read uses the same identity (owner vs account) as the downstream fee/cost-basis math; mismatched identities yield both DoS (div-by-zero) and silent fee mispricing.