The Idols NFT Exploit: How a Self-Transfer Bug Drained $340K in stETH

On January 14, 2025, The Idols NFT contract @TheIdolsNFT on Ethereum was exploited, resulting in a $340K loss in stETH. The attack leveraged flawed logic in the _beforeTokenTransfer function, where self-transfers of NFTs reset reward records, allowing repeated claims of inflated stETH rewards..

1. The attacker exploited the safeTransferFrom function by repeatedly transferring a token (tokenId 940) within their own contract, bypassing whitelist checks.
2. This manipulation triggered reward updates in the _beforeTokenTransfer hook, allowing the attacker to falsely inflate reward snapshots.
3. By repeatedly calling _claimEthRewards, the attacker claimed large rewards due to an inflated rewardPerGod value while resetting claimedSnapshots to zero for each transfer.
4. Using multiple contracts, the attacker repeated the exploit, ultimately draining around $340,000 worth of funds.

The Idols is a collection of 10,000 generative portraits living on the Ethereum blockchain. Each Idol is unique and is generated from over a hundred hand-drawn assets. Some Idols will have features that are rarer than others, however, since all Idols will have an equal claim on the income generated from the Idol Treasury, all Idols will have an identical intrinsic value.

Exploit Overview:

Vulnerable Contract: 0x439cac

Attacker Address: 0xE5464

Attack Transactions:  0xa8289, 0x9ac08,  0x45d93,  0x5e989,  0x14ae4, 0x1aaa3, 0xa194e,  ****0xd9870,  0x2bda7,  0xa64b6,  0x61092, 0xbffcf,  0x45bf5, 0x1a595.

The attacker repeatedly called the safeTransferFrom function with their contract address as both the from and toarguments while passing their tokenId (940). This allowed them to exploit the contract’s logic by initiating a transfer without actually moving the token between accounts.

Normally, the safeTransferFrom function restricts token transfers to whitelisted addresses. However, since the from and to arguments in the attacker’s calls were the same (their contract address), the transfer appeared valid, bypassing the whitelist restriction.

The _beforeTokenTransfer hook contained logic to manage reward snapshots:

• When a user transfers their last NFT, it deletes their associated data.

• When a user receives an NFT, it initializes or updates their reward. The attacker leveraged this to manipulate reward data.

  

_claimEthRewards(_from) calculates the amount of unclaimed stETH of _from . This internal function calculates based on the (balanceOf(_user) * (rewardPerGod - claimedSnapshots[_user]))

claimedSnapshots[_from] is deleted and after that _claimEthRewards(_to) is called since the balanceOf from and to is 1.

Here, getPendingStethReward(_to) returns the 31,551,801,208,076,112 since claimedSnapshots[_user] is zero , balanceOf user is 1 and rewardPerGod is 31,551,801,208,076,112.

Inside the _claimEthRewards(), the claimedSnapshots[_user] is again updated to rewardPerGod . The attacker was able to perform repeated self-transfers, exploiting the reward system to claim additional rewards continuously.

To scale the exploit, the attacker deployed multiple contracts and repeated the process across them, ultimately draining approximately $340,000 worth of funds.

The attacker exploited the fact that transferring tokens from and to the same address bypassed whitelist checks, allowing repeated self-transfers. This triggered the _beforeTokenTransfer hook, which manipulated reward data by resetting or recalculating snapshots. The attacker claimed excessive rewards repeatedly by exploiting the disparity between rewardPerGod and claimedSnapshots[_user], draining approximately $340,000 worth of funds.

Response from The Idols NFTs

The team mentioned that they were actively investigating the issue and exploring all possible options to resolve the situation promptly.

1. Ensure that the reward snapshot reset (e.g., claimedSnapshots[_user] = rewardPerGod) occurs only when a token is transferred to a new user, not during self-transfers. This would stop users from exploiting the system by repeatedly resetting their own rewards.
2. Implement a check to ensure that rewards are only claimed when the recipient (_to) is a distinct address. This would prevent reward claims in the case of self-transfers .
3. Implement a condition in the _beforeTokenTransfer function to detect and skip reward claims when the fromand to addresses are the same. This would prevent rewards from being claimed during self-transfers.
4. Collaborate with reputable audit firms like QuillAudits to analyse smart contracts and identify these type of vulnerabilities.

Secure Your Web3 Project with QuillAudits

Choosing a reputable audit firm like QuillAudits ensures your protocol undergoes rigorous scrutiny from experienced security professionals. We specialize in uncovering critical vulnerabilities and delivering actionable remediation strategies to keep your project protected. Security isn’t optional—it’s the foundation of trust.

Stay Ahead with Expert Security Insights

Access in-depth security blogs, research reports, and updates from QuillAudits. Stay informed, stay secure.