Back to Blog

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

Code Auditing
February 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
Beyond Secure Storage, Part 2: Implementing Wallet Cryptography Securely
Security Insights

Beyond Secure Storage, Part 2: Implementing Wallet Cryptography Securely

Can an attacker recover a private key without reading its protected copy? Part 2 of Beyond Secure Storage examines six incidents in which weak randomness, entropy loss, or signing nonce flaws made keys predictable or recoverable. It derives implementation requirements for key generation and signing, then explains how payment institutions can assess them through code review and testing of the deployed system.

Beyond Secure Storage, Part 1: Designing Secure Payment and Signing Workflows
Security Insights

Beyond Secure Storage, Part 1: Designing Secure Payment and Signing Workflows

How can an unauthorized operation obtain a valid signature without the attacker stealing the private key? Part 1 of Beyond Secure Storage uses incidents including Bitget, Bybit and Binance to examine authorization failures across payment requests, transaction construction, signing, execution and settlement. It derives design principles for preventing unauthorized operations and limiting losses, then explains how reviews, audits, penetration tests and exercises can verify those protections.

NEAR Intents Exploit: Refund Flaw and Security Lessons
Security Insights

NEAR Intents Exploit: Refund Flaw and Security Lessons

The NEAR Intents exploit used oversized refund events to preserve internal balances after the deposited assets were returned. This analysis reconstructs the receipt flow and seven BNB Chain withdrawals totaling 3,865,021 USDT, distinguishes those outflows from the project's reported full recovery, and outlines security considerations for developing and auditing NEAR smart contracts.

Best Security Auditor for Web3

Validate design, code, and business logic before launch. Aligned with the highest industry security standards.

BlockSec Audit