# `Kelp:_finalizeCooldown` cannot claim the withdrawal if adversary would requestWithdrawals with dust amount for the holder

KelpCooldownHolder._finalizeCooldown claims only request index 0 from LidoWithdraw, so an attacker's dust withdrawal request locks the real withdrawal permanently.

- Payout: Contest reward
- Severity: high
- Program: Leveraged Vaults
- Credited: BiasedMerc
- Disclosed: 2024-06-18
- Write-up quality: 7/10
- Original: https://github.com/sherlock-audit/2024-06-leveraged-vaults-judging/issues/105
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-06-leveraged-vaults%3AH-13
- Tags: domain:web3 impact:dos impact:funds-loss kind:contest platform:sherlock sev:high tech:evm tech:solidity technique:source-review vuln:business-logic vuln:dos

**Target:** KelpCooldownHolder / LidoWithdraw integration in Kelp.sol
**Root cause:** _finalizeCooldown hardcodes claiming the 0-th request from LidoWithdraw.getWithdrawalRequests instead of the holder's actual requestId, so any earlier injected request shadows the real one.
**Steps:**
1. Attacker calls `LidoWithdraw.requestWithdrawals([100], KelpCooldownHolder)` with dust stETH before the holder's triggerExtraStep.
2. Holder's real withdrawal request is appended after the dust request, becoming index 1.
3. On exitVault, `_finalizeCooldown` calls `claimWithdrawal` on request index 0 (the dust request) only.
4. accountWithdrawRequest is deleted; onlyVault modifier blocks re-calling finalizeCooldown; rescueTokens cannot recover stETH already sent to LidoWithdraw.
5. Real withdrawal remains locked permanently.
**How found:** Code reading of _finalizeCooldown revealed it indexes getWithdrawalRequests[0] rather than tracking the requestId returned by requestWithdrawals; noted LidoWithdraw.requestWithdrawals is permissionless with arbitrary _owner, enabling front-running injection.
**Exploitation:** Attacker needs only dust stETH and front-runs the holder's triggerExtraStep by calling LidoWithdraw.requestWithdrawals with the holder's address as owner, shifting the real request off index 0. The vault's finalize then claims the dust request, deleting state and permanently locking the real stETH withdrawal.
**Escalation:** Loss of the entire withdrawal and potential undervaluation of the account's collateral leading to unexpected liquidation.
**Insight:** When integrating with permissionless queue-based withdrawal systems (Lido, Ethena, etc.), never assume your request is at a fixed index; store the returned requestId and claim by ID, since anyone can inject requests for your contract's address.