# Absence of restrictions on the sender of the twTAP.claimsReward() function could enable attackers to freeze reward tokens within the Tap token contract

Anyone can call twTAP.claimRewards for an approved receiver, front-running cross-chain claim messages so rewards land in TapTokenReceiver and get permanently trapped.

- Payout: Contest reward
- Severity: high
- Program: Tapioca DAO
- Credited: KIntern\_NA
- Disclosed: 2024-05-23
- Write-up quality: 7/10
- Original: https://github.com/code-423n4/2024-02-tapioca-findings/issues/142
- Library page: https://bugbountylibrary.com/r/c4%3A2024-02-tapioca%3AH-03
- 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:** twTAP governance contract and TapTokenReceiver cross-chain claim handler
**Root cause:** claimRewards only checks permission on the _to receiver, not msg.sender, so any caller can trigger a claim to an approved address before the intended cross-chain claim message executes.
**Steps:**
1. Owner approves TapTokenReceiver for _tokenId via a LayerZero permit message (anyone can relay it).
2. Attacker calls `twTAP.claimRewards(_tokenId, TapTokenReceiver)` before the claim message is delivered.
3. Rewards are sent to TapTokenReceiver; later `_claimTwpTapRewardsReceiver` calls claimRewards again and gets 0 amounts.
4. Rewards remain stuck in TapTokenReceiver with no path to the destination receiver.
**How found:** Code review of claimRewards permission model: noticed _requireClaimPermission only validates _to, allowing arbitrary msg.sender, then traced the cross-chain claim flow in TapTokenReceiver to find the front-runnable window between permit and claim messages.
**Exploitation:** Attacker monitors pending permit/claim composed messages, relays the permit on the destination chain, then front-runs the claim message with a direct claimRewards call to the receiver contract, zeroing the subsequent claim and freezing funds.
**Insight:** When a claim/withdraw helper checks permission only on the recipient, look for cross-chain or two-step flows where an attacker can pre-execute the claim to a shared receiver contract and zero out the legitimate call's return value.