# VaultRouter cannot be used for deposits when it reaches the maximum deposit limit

VaultRouter is msg.sender for vault deposits, so once the router's own balance hits the per-wallet max deposit limit, all router deposits revert, enabling DoS.

- Payout: Audit contest
- Severity: medium
- Program: BakerFi
- Credited: 0xlemon
- Disclosed: 2025-02-26
- Write-up quality: 6/10
- Original: https://code4rena.com/reports/2024-12-bakerfi-invitational#m-15
- Library page: https://bugbountylibrary.com/r/c4%3A2024-12-bakerfi-invitational%3AM-15
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:business-logic vuln:dos

**Target:** VaultRouter / VaultBase deposit path (Solidity contracts)
**Root cause:** Vault enforces per-depositor max deposit using balanceOf(msg.sender); when deposits flow through VaultRouter, msg.sender is the router, so the router's aggregate balance counts against the limit.
**Steps:**
1. Call VaultRouter deposit with receiver set to the router address itself, depositing up to getMaxDeposit().
2. Immediately withdraw in the same transaction so funds aren't lost.
3. Router's balanceOf now equals/exceeds maxDepositLocal; subsequent `_depositInternal` calls via router revert with `MaxDepositReached()`.
4. All users' router-based deposits are blocked (DoS).
**How found:** Code reading of `_depositInternal` revealed the limit check uses `balanceOf(msg.sender)`; noting VaultRouter is the msg.sender for routed deposits exposed the shared-limit flaw.
**Exploitation:** Attacker uses router to deposit with receiver=router, then withdraws atomically in the same tx, saturating the router's per-wallet deposit limit without risking capital, permanently blocking router deposits for everyone.
**Insight:** When a shared router/aggregator contract is the msg.sender to a per-address-limited vault, the limit applies to the router's aggregate balance, not the end user — check every per-msg.sender accounting check for router-mediated flows.