# Adversary can steal approved tOLPs to Magnetar via _paricipateOnTOLP

Magnetar's _participateOnTOLP trusts a caller-supplied tOLPTokenId without ownership check, letting anyone lock another user's approved tOLP and mint the oTAP NFT to themselves.

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

**Target:** Magnetar _participateOnTOLP / TapiocaOptionBroker
**Root cause:** _participateOnTOLP accepts participateData.tOLPTokenId and calls IERC721(lockDataTarget).approve then participate() without verifying the caller owns that tOLP; lockDataTarget is attacker-controlled and unused elsewhere.
**Steps:**
1. Attacker calls Magnetar with participateData.tOLPTokenId set to a victim's tOLP id that is approved to Magnetar.
2. Set participateData.target to a whitelisted TapiocaOptionBroker.
3. Set lockDataTarget to an attacker-controlled contract whose approve() does not revert (Magnetar isn't owner of the token).
4. Magnetar calls approve(target, victimTokenId) on the fake lockDataTarget, then ITapiocaOptionBroker(target).participate(victimTokenId).
5. Broker locks victim's tOLP and mints oTAP NFT; Magnetar safeTransferFrom's the oTAP to the attacker.
**How found:** Code reading of _participateOnTOLP: noticed tOLPTokenId is overwritten from user-supplied participateData without an ownerOf check, and that lockDataTarget is only used for an approve call that can be redirected to a no-op contract.
**Exploitation:** Attacker supplies a malicious lockDataTarget so the approve call succeeds despite Magnetar not owning the token, then invokes participate on a whitelisted broker with the victim's approved tOLP id, receiving the minted oTAP NFT while the victim's tOLP is locked.
**Insight:** When a router/helper contract holds approvals, audit every user-supplied token id for an ownerOf/msg.sender check; also flag any address parameter used solely for an approve() call, since it can be swapped for a no-op to bypass the ownership revert.
