# YIEDL SportVault: zero-share redeem drains vault funds

YIEDL SportVault redeem lacked input validation on sharesToRedeem, letting attacker pass 0 shares and drain ~150k USD via repeated calls.

- Payout: Real-world hack
- Severity: high
- Program: YIEDL
- Analysis by: DeFiHackLabs
- Disclosed: 2024-04-24
- Write-up quality: 6/10
- Original: https://github.com/SunWeb3Sec/DeFiHackLabs/blob/main/src/test/2024-04/YIEDL_exp.sol
- Library page: https://bugbountylibrary.com/r/dhl%3A20240424-yiedl
- Tags: domain:web3 impact:funds-loss kind:incident platform:defihacklabs sev:high tech:evm technique:source-review vuln:business-logic

**Target:** SportVault redeem function on BSC
**Root cause:** The redeem function did not validate that sharesToRedeem > 0, allowing a caller to redeem zero shares while still receiving underlying assets via the dataList swap calls.
**Steps:**
1. Deploy attacker contract on BSC fork at block 38126753.
2. Prepare dataList array of 11 bytes elements; first three are `unoswapTo(Attacker, USDC, 2331516232778274153239, 0, pools)` etc. for USDC, BTCB, BETH.
3. Call `sportVault.redeem(0, address(BUSD), 0, dataList, false)` repeatedly (20 times).
4. Each call transfers tokens to attacker via the swap calls despite zero shares redeemed.
**Exploitation:** Attacker calls redeem with sharesToRedeem=0 and a crafted dataList that executes swaps sending vault-held USDC, BTCB, BETH to the attacker. Repeated 20 times to drain ~150k USD.
**Insight:** When a vault's redeem/withdraw function accepts a shares amount and a list of external calls, test zero or negative shares to see if asset transfers still occur without burning shares.