# Adversary can utilise approved to Magnetar oTAP and tOLP NFTs

Magnetar's _processTapTokenOperation lacked ownership checks, letting anyone exercise or lock another user's approved oTAP/tOLP NFTs via batched calls.

- Payout: Contest reward
- Severity: high
- Program: Tapioca DAO
- Credited: deadrxsezzz
- Disclosed: 2024-05-23
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2024-02-tapioca-findings/issues/45
- Library page: https://bugbountylibrary.com/r/c4%3A2024-02-tapioca%3AH-11
- 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:** Magnetar batch-executor contract (TapiocaOptionBroker / TapiocaOptionLiquidityProvision)
**Root cause:** Magnetar's _processTapTokenOperation forwards whitelisted calls (exerciseOption, participate, exitPosition, lock, unlock) without verifying msg.sender owns or is approved for the referenced NFT, relying only on the NFT contract's isApprovedOrOwner check against Magnetar itself.
**Steps:**
1. User approves Magnetar for their oTAP/tOLP NFT to enable batching.
2. Attacker calls Magnetar with actionCalldata targeting TapiocaOptionBroker.exerciseOption for victim's _oTAPTokenID.
3. Magnetar passes the call through; oTAP.isApprovedOrOwner(Magnetar, id) returns true due to prior approval.
4. Victim's option is exercised with attacker-chosen payment token and tapAmount, consuming the victim's eligible amount.
**How found:** Code review of Magnetar's _processTapTokenOperation whitelist dispatch, noticing it forwards NFT-scoped calls without checking the caller against the NFT owner, while the underlying functions only check isApprovedOrOwner(msg.sender) where msg.sender is Magnetar.
**Exploitation:** Attacker crafts a Magnetar batch call invoking exerciseOption (or lock/unlock/participate/exitPosition) on a victim's approved NFT ID; Magnetar's approval satisfies isApprovedOrOwner, so the action executes against the victim's position, letting the attacker consume the victim's option eligibility or manipulate their lock.
**Insight:** When a batch-executor contract holds NFT/token approvals and forwards calls, the downstream isApprovedOrOwner check validates the executor, not the end user—always verify the original caller owns the token ID inside the executor.