# A malicious receiver can cause another receiver to lose out on distributed fees by returning false for tokensReceived when receiveRewards is called on their receiver contract.

A malicious receiver returns false from tokensReceived during receiveRewards, tricking NFTXFeeDistributor into double-spending amountToSend and denying fees to other receivers.

- Payout: Audit contest
- Severity: medium
- Program: NFTX
- Disclosed: 2021-06-21
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2021-05-nftx-findings/issues/69
- Library page: https://bugbountylibrary.com/r/c4%3A2021-05-nftx%3AM-08
- Tags: area:web3 domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** NFTXFeeDistributor.sol receiveRewards receiver call
**Root cause:** The distributor trusts the boolean return data from an external receiver's tokensReceived call instead of only checking call success, so a receiver can lie about failure and trigger the fallback path while still receiving funds.
**Steps:**
1. Attacker deploys a receiver contract whose tokensReceived returns false.
2. receiveRewards is called and the distributor invokes `address(_receiver.receiver).call(payload)` at line 163.
3. The call succeeds but returnData decodes to false, so the distributor treats it as failure and routes amountToSend to the treasury fallback.
4. Result: amountToSend is effectively double-spent and other receivers lose their share of distributed fees.
**How found:** Code review of the fee distributor's external call handling; noticed the contract decodes and trusts returnData from an untrusted receiver contract instead of relying on the call's success flag.
**Exploitation:** A malicious receiver contract returns false from tokensReceived; the distributor's check on the returned data (rather than on call success) causes it to double-spend amountToSend, denying fees to honest receivers.
**Insight:** When a contract calls an untrusted receiver and branches on decoded return data, check whether the success flag alone should gate the fallback; a receiver can return false while still executing, causing double-spend or denial to other recipients.