# Reentrancy issue in yVault.deposit

yVault.deposit caches balance before transferFrom, letting an ERC777-style reentrant deposit mint excess shares and drain the vault.

- Payout: Audit contest
- Severity: high
- Program: JPEG'd
- Credited: cmichel
- Disclosed: 2022-06-10
- Write-up quality: 7/10
- Original: https://github.com/code-423n4/2022-04-jpegd-findings/issues/81
- Library page: https://bugbountylibrary.com/r/c4%3A2022-04-jpegd%3AH-04
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:evm tech:solidity technique:source-review vuln:reentrancy vuln:share-inflation

**Target:** yVault deposit function (Solidity vault contract)
**Root cause:** deposit() reads balanceBefore, then calls token.transferFrom (which can hand control to the sender for ERC777-like tokens) before minting shares, so a reentrant deposit reuses the stale balanceBefore.
**Steps:**
1. Initial state: balance()=1000, supply=1000.
2. Outer `deposit(500)`: balanceBefore=1000, transferFrom gives control to attacker.
3. Inner `deposit(500)`: balanceBefore=1000, mints 500*1000/1000=500 shares.
4. Outer resumes: mints 500*1500/1000=750 shares.
5. Attacker holds 1250 shares; `withdraw(1250)` returns 2000*1250/2250=1111 tokens, profit ~111.
6. Repeat until vault drained.
**How found:** Code reading of deposit: noticed balance cached before an external transferFrom call, a classic reentrancy pattern when token gives control to sender.
**Exploitation:** Attacker uses an ERC777-style token whose transferFrom reenters deposit; the stale cached balance inflates share minting, then withdraws inflated shares for more backing tokens than deposited.
**Escalation:** Repeat the deposit/withdraw cycle to drain the vault.
**Insight:** In vault share math, any external token call between reading balance/supply and minting shares is reentrancy-exploitable; check ERC777/hook tokens and whether balanceBefore is refreshed after transferFrom.