# Tokens can be stolen from other users who have approved Magnetar

Magnetar helper functions like MARKET_BUY_COLLATERAL and depositRepayAndRemoveCollateralFromMarket omit _checkSender, letting attackers spend other users' approvals to Magnetar and steal or lever their tokens.

- Payout: Contest reward
- Severity: high
- Program: Tapioca DAO
- Credited: dirk\_y
- Disclosed: 2023-11-16
- Write-up quality: 7/10
- Original: https://github.com/code-423n4/2023-07-tapioca-findings/issues/351
- Library page: https://bugbountylibrary.com/r/c4%3A2023-07-tapioca%3AH-56
- Tags: 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:** MagnetarV2 / MagnetarMarketModule helper contract
**Root cause:** Several Magnetar action handlers accept an arbitrary `from`/`user` address without calling `_checkSender`, so the market sees Magnetar as msg.sender and consumes the victim's borrow allowance or token approval to Magnetar.
**Steps:**
1. Victim approves Magnetar as spender of tokens / grants borrow allowance to Magnetar.
2. Attacker calls Magnetar with MARKET_BUY_COLLATERAL action, setting `data.from` to victim address and supplying borrowAmount/supplyAmount.
3. Magnetar calls `IMarket(data.market).buyCollateral(data.from, ...)`; market's `_allowedBorrow` sees msg.sender=Magnetar and consumes victim's allowance, levering victim's position.
4. Alternatively call `depositRepayAndRemoveCollateralFromMarket` with `extractFromSender=false` and `user=victim`; `_extractTokens(user, assetAddress, depositAmount)` pulls victim's approved tokens into YieldBox.
**How found:** Code review of Magnetar action handlers comparing which methods call `_checkSender`; noticed MARKET_BUY_COLLATERAL and depositRepayAndRemoveCollateralFromMarket lacked the check while accepting arbitrary `from`/`user`.
**Exploitation:** Attacker crafts a Magnetar multicall/action with victim address as `from`/`user`; Magnetar's own approval to the market/YieldBox is used to move victim funds or increase victim LTV, enabling liquidation profit or direct token drain into attacker-controlled YieldBox position.
**Escalation:** Levering victim position raises LTV toward insolvency, enabling profitable liquidation; direct deposit path drains approved tokens.
**Insight:** In helper/router contracts that hold user approvals, enumerate every action handler and verify each one binds the `from`/`user` parameter to msg.sender; any handler that forwards a user-supplied address to a downstream contract (which then sees the router as msg.sender) is an approval-drain primitive.