# If a user approves junior vault tokens to WithdrawPeriphery, anyone can withdraw/redeem his/her token

WithdrawPeriphery.withdrawToken/redeemToken take an arbitrary `from` address, so anyone can spend a victim's junior vault share allowance to withdraw or redeem their tokens.

- Payout: Contest reward
- Severity: high
- Program: Rage Trade
- Credited: Nyx
- Disclosed: 2022-10-28
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2022-10-rage-trade-judging/issues/79
- Library page: https://bugbountylibrary.com/r/sherlock%3A2022-10-rage-trade%3AH-1
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:high tech:evm tech:solidity technique:source-review vuln:access-control vuln:business-logic

**Target:** WithdrawPeriphery periphery contract (Solidity/EVM)
**Root cause:** withdrawToken() and redeemToken() pass a caller-supplied `from` into dnGmxJuniorVault.withdraw/redeem instead of using msg.sender, so the contract spends any allowance granted to it on behalf of an arbitrary user.
**Steps:**
1. Victim approves WithdrawPeriphery for dnGmxJuniorVault shares (often type(uint256).max via UI).
2. Attacker calls `withdrawToken(victim, token, attacker, sGlpAmount)` or `redeemToken(victim, token, attacker, sharesAmount)`.
3. Periphery invokes `dnGmxJuniorVault.withdraw(sGlpAmount, address(this), victim)`, consuming the victim's allowance.
4. Attacker receives the withdrawn/redeemed assets at `receiver`.
**How found:** Code review of the periphery's withdraw/redeem entrypoints noticed the `from` parameter is user-controlled and forwarded to the vault call rather than bound to msg.sender, making the allowance spendable by anyone.
**Exploitation:** Attacker needs only the victim's address and an existing allowance to WithdrawPeriphery; with max approval the theft is repeatable at will, otherwise the attacker frontruns the victim's own withdraw/redeem tx and redirects the output to themselves.
**Insight:** In periphery/router contracts that pull tokens via allowance, any user-supplied `from`/`onBehalfOf` parameter is a theft primitive unless bound to msg.sender or gated by signature; check every external function that forwards an address into a vault's transferFrom-style call.