# Users can get around MaxLTV because of lack of strategyId validation

IchiVaultSpell.reducePosition accepts any strategyId for the MaxLTV check, letting users withdraw collateral against a stricter strategy while validating against a looser one.

- Payout: Contest reward
- Severity: high
- Program: Blueberry
- Credited: 8olidity
- Disclosed: 2023-02-01
- Write-up quality: 7/10
- Original: https://github.com/sherlock-audit/2023-02-blueberry-judging/issues/129
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-02-blueberry%3AH-5
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:high tech:solidity technique:source-review vuln:access-control vuln:business-logic

**Target:** IchiVaultSpell.reducePosition / _validateMaxLTV (Solidity lending spell)
**Root cause:** _validateMaxLTV(strategyId) trusts a caller-supplied strategyId without verifying it matches the position's actual collateral vault, so maxLTV is read from an arbitrary strategy.
**Steps:**
1. User opens position on risky strategy 911 (maxLTV[911][DAI]=2e5) with 1000 DAI collateral, borrows $2000.
2. Call `reducePosition(411, DAI, 1600)` passing safer strategy 411 (maxLTV[411][DAI]=4e5) as strategyId.
3. doWithdraw/doRefund remove 1600 DAI collateral.
4. _validateMaxLTV(411) checks against the looser LTV and passes, leaving 400 DAI backing $2000 debt.
**How found:** Code review of reducePosition: noticed strategyId is a free parameter passed straight into _validateMaxLTV with no binding to the position's collateral token/vault.
**Exploitation:** Attacker borrows to the max on a strict-LTV strategy, then repeatedly calls reducePosition with a permissive strategyId to withdraw collateral, achieving leverage far above the protocol's allowed LTV.
**Escalation:** Higher leverage on risky assets increases protocol insolvency risk if prices swing before liquidation can protect solvency.
**Insight:** When a validation function takes an identifier as an argument, check whether that identifier is bound to the caller's actual position state; unbound IDs let users pick the most favorable config for the check.