When “SafeMint” Becomes Unsafe: Lessons from the HypeBears Security Incident
Feb 3 2022

On the morning of Feb 3rd (+8 timezone), our system reported an attack transaction 0xfa97c3476aa8aeac662dae0cc3f0d3da48472ff4e7c55d0e305901ec37a2f704 towards the HypeBears NFT contract. After the investigation, we found it's a re-entrancy attack caused by the _safeMint function of ERC721.

The root cause

The project has a limitation of the NTFs that an account can mint. Basically, it has a map addressMinted that logs whether an account has minted the NTFs.

When minting NFTs, the code uses _safeMint function of the OZ reference implementation. This function is safe because it checks whether the receiver can receive ERC721 tokens. The can prevent the case that a NFT will be minted to a contract that cannot handle ERC721 tokens. According to the document:

If to refers to a smart contract, it must implement IERC721Receiver.onERC721Received, which is called upon a safe transfer. The following code shows the OZ implementation of _safeMint function.

However, this external function call creates a security loophole. Specifically, the attacker can perform a reentrant call inside the onERC721Received callback. For instance, in the vulnerable HypeBears contract, the attacker can invoke the mintNFT function again in the onERC721Received callback (since 1addressMinted` has not been updated.)

The attack

The following screenshot shows the attack transaction.

Lessons

The risk called by SafeMint has been discussed by security researchers link1 link2. However, we can still see the vulnerable code and the attack in the wild. As shown in the safeTransfer in QBridge security incident, using a safe function does not guarantee a safe contract 😃.

Sign up for the latest updates
#10: ThirdWeb Incident: Incompatibility Between Trusted Modules Exposes Vulnerability
Security Insights

#10: ThirdWeb Incident: Incompatibility Between Trusted Modules Exposes Vulnerability

This blog shows the vulnerability and attack caused by Incompatibility of commonly used modules.

#9: MEV Bot 0xd61492: From Predator to Prey in an Ingenious Exploit
Security Insights

#9: MEV Bot 0xd61492: From Predator to Prey in an Ingenious Exploit

On August 3, 2023, an MEV Bot on Arbitrum was attacked, resulting in $800K in loss. The root cause of this attack was **Insufficient User Input Verification**.

#8: SushiSwap Incident: A Clumsy Rescue Attempt Leads to a Series of Copycat Attacks
Case Studies

#8: SushiSwap Incident: A Clumsy Rescue Attempt Leads to a Series of Copycat Attacks

On April 9, 2023, SushiSwap became the target of an exploit due to an Unverified External Parameter. The total loss is about $3.3 million.

BlockSec uses cookies and other identifiers to analyze our traffic in accordance. We also share information about your use of our site with our analytics partners. By remaining on this website, you consent to our use of cookies and the Privacy Policy.