# Missing check on helper contract allows arbitrary actions and theft of assets

MagnetarOptionModule fails to whitelist the marketHelper contract, letting an attacker return arbitrary repay/removeCollateral calldata and drain other users' BigBang positions via Magnetar's approvals.

- Payout: Contest reward
- Severity: high
- Program: Tapioca DAO
- Credited: carrotsmuggler
- Disclosed: 2024-05-23
- Write-up quality: 7/10
- Original: https://github.com/code-423n4/2024-02-tapioca-findings/issues/179
- Library page: https://bugbountylibrary.com/r/c4%3A2024-02-tapioca%3AH-02
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:evm tech:solidity technique:incomplete-fix technique:source-review vuln:access-control vuln:business-logic

**Target:** MagnetarOptionModule.exitPositionAndRemoveCollateral in Magnetar router
**Root cause:** data.externalData.marketHelper is used to build repay/removeCollateral calldata without a whitelist check, unlike other Magnetar modules. The resulting modules/calls are executed by bigBang_.execute with Magnetar as msg.sender, which holds user approvals.
**Steps:**
1. Attacker deploys a malicious contract implementing IMarketHelper.repay/removeCollateral that returns arbitrary Module[] and bytes[] calls (e.g. borrow or removeCollateral for a victim).
2. Attacker calls `MagnetarOptionModule.exitPositionAndRemoveCollateral(data)` with `data.user = attacker` (passes `_checkSender`) and `data.externalData.marketHelper = maliciousHelper`.
3. Module builds calls via `IMarketHelper(marketHelper).repay(address(this), data.user, false, repayAmount)` returning attacker-controlled payload.
4. `bigBang_.execute(modules, calls, true)` runs the payload with Magnetar as msg.sender, satisfying `_allowedBorrow`/allowance checks against Magnetar's approvals for the victim.
5. Attacker borrows USDO or removes collateral from victim's BigBang position, extracting funds.
**How found:** Code review comparing MagnetarOptionModule against other modules (e.g. MagnetarMintCommonModule) revealed marketHelper whitelist check present elsewhere but missing here; traced the unchecked helper output into bigBang_.execute and confirmed market-side allowance checks key on msg.sender (Magnetar), not the initiator.
**Exploitation:** Precondition: victim has granted Magnetar borrow/collateral approvals (idle allowance). Attacker passes _checkSender by setting data.user to self, supplies malicious marketHelper returning borrow/removeCollateral calldata targeting victim, and Magnetar executes it under its own privileged approvals, draining victim collateral or borrowing USDO against their position.
**Escalation:** Any user with pending Magnetar allowance is exploitable; same pattern as Sushi router approval-drain.
**Insight:** When a router/aggregator holds user approvals, audit every externally-supplied helper/calldata-builder address for whitelisting; downstream allowance checks keyed on msg.sender (the router) do not protect the original user, so any unvalidated calldata source becomes approval hijacking.