# Attacker can steal victim's oTAP position contents via MagnetarMarketModule#_exitPositionAndRemoveCollateral()

Magnetar's exit function trusts caller-supplied user and target addresses, letting an attacker exit a victim's approved oTAP position and unlock its yieldbox shares to themselves.

- Payout: Contest reward
- Severity: high
- Program: Tapioca DAO
- Credited: Ack
- Disclosed: 2023-11-16
- Write-up quality: 7/10
- Original: https://github.com/code-423n4/2023-07-tapioca-findings/issues/936
- Library page: https://bugbountylibrary.com/r/c4%3A2023-07-tapioca%3AH-42
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:evm tech:solidity technique:chained technique:source-review vuln:access-control vuln:business-logic

**Target:** MagnetarMarketModule#_exitPositionAndRemoveCollateral (Solidity periphery contract)
**Root cause:** The multi-purpose function accepts caller-controlled `user`, `externalData.singularity`, and `unlockData.target` without requiring user == msg.sender or validating addresses, so any caller can operate on a victim's approved oTAP position and route unlock to an attacker contract.
**Steps:**
1. Victim approves Magnetar to transfer their oTAP ERC721 position.
2. Attacker calls `_exitPositionAndRemoveCollateral()` with `exitData.exit=true`, `unlockData.unlock=true`, `user=victim`, victim's `oTAPTokenID`, and `unlockData.target` = attacker contract whose `.unlock()` no-ops.
3. Magnetar safeTransferFrom's the oTAP to itself, calls `exitPosition`, and retains the resulting yieldbox shares.
4. Attacker calls `_exitPositionAndRemoveCollateral()` again with `exitData.exit=false`, `unlockData.unlock=true`, `user=attacker`, same tokenId, and `unlockData.target` = real tOLP contract, unlocking shares to attacker.
**How found:** Code review of the multi-flag `_exitPositionAndRemoveCollateral` function: noticed all target addresses and `user` come from caller input with no msg.sender check, and that the two-phase exit/unlock flow lets the caller retain shares inside Magnetar between calls.
**Exploitation:** Precondition: victim has approved Magnetar for their oTAP NFT. Attacker supplies attacker-controlled target/singularity addresses to first pull the NFT into Magnetar and exit it (skipping the return transfer by setting unlock=true), then a second call with the real tOLP contract and attacker as `user` unlocks the yieldbox shares to the attacker.
**Insight:** In multi-operation periphery functions that take a `user` parameter plus arbitrary contract addresses, check whether the function ever enforces user==msg.sender; if not, any prior approval to the periphery becomes stealable by chaining two calls that leave assets parked in the contract between operations.