# All user assets which are approved to VaderPoolV2 may be stolen

VaderPoolV2.mintFungible accepts a user-supplied `from` address, letting an attacker mint LP tokens against any victim's token approval and steal their funds.

- Payout: Audit contest
- Severity: high
- Program: Vader Protocol
- Found by: TomFrenchBlockchain
- Disclosed: 2022-02-10
- Write-up quality: 7/10
- Original: https://github.com/code-423n4/2021-11-vader-findings/issues/221
- Library page: https://bugbountylibrary.com/r/c4%3A2021-11-vader%3AH-26
- Tags: area:web3 domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:evm tech:solidity technique:source-review vuln:access-control vuln:business-logic

**Target:** VaderPoolV2 DEX pool contract, mintFungible function
**Root cause:** mintFungible pulls nativeAsset and foreignAsset from a caller-supplied `from` address instead of msg.sender, and lacks the onlyRouter modifier, so any approved address's tokens can be spent.
**Steps:**
1. Victim approves VaderPoolV2 to spend their tokens (standard DEX interaction).
2. Attacker calls `mintFungible(from=victim, ...)` on VaderPoolV2.
3. Contract pulls victim's nativeAsset/foreignAsset via transferFrom using the existing approval.
4. Attacker receives fungible LP tokens representing the stolen underlying assets.
**How found:** Code review of mintFungible noticed the `from` parameter is user-controlled rather than msg.sender, and that minting functions lacked the onlyRouter modifier, implying any approved address could be drained.
**Exploitation:** Attacker supplies any address holding an approval to VaderPoolV2 as `from`; the pool pulls that victim's tokens and mints LP tokens to the attacker, who can redeem/withdraw the underlying value.
**Insight:** On DEX/pool contracts, check every function that calls transferFrom: if the source address is a parameter rather than msg.sender, any outstanding approval becomes stealable. Also verify router-only functions actually carry the onlyRouter modifier.