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
~$800K Lost: Hinkal Double-Spend | BlockSec Weekly
Security Insights

~$800K Lost: Hinkal Double-Spend | BlockSec Weekly

This weekly security report covers 1 notable incident from June 29 to July 5, 2026, with approximately $800K in total losses on Ethereum. The Hinkal shielded-pool protocol was drained through a double-spend attack that likely exploited a flaw in the legacy note format, allowing the attacker to derive multiple nullifiers from a single deposit. The report analyzes the probable circuit-level vulnerability, the attack flow, and broader implications for nullifier-based privacy protocols.

Newsletter - June 2026
Security Insights

Newsletter - June 2026

This monthly report covers the three largest security incidents in June 2026, totaling approximately $22M in confirmed losses. A sophisticated honeypot attack drained ~$15M from JaredFromSubway's MEV bot by exploiting unchecked token allowances. Two legacy Aztec rollup deployments lost ~$4.35M through proof-settlement boundary gaps. SecondFi's Ed25519 implementation flaw exposed wallet private keys, resulting in ~$2.4M drained from 374 wallets. All three incidents share a common pattern: security guarantees that appeared intact on the surface but were never actually enforced.

~$4.1M Lost: Taiko, SecondFi Exploits | BlockSec Weekly
Security Insights

~$4.1M Lost: Taiko, SecondFi Exploits | BlockSec Weekly

This weekly blockchain security report covers two notable incidents from June 22-28, 2026, with approximately $4.1M in confirmed losses across Ethereum and Cardano. The Taiko bridge exploit combined an exposed SGX enclave signing key with an incomplete attestation policy that failed to reject debug enclaves, allowing the attacker to register a malicious prover and forge L2 state proofs on Ethereum. The SecondFi wallet vulnerability stemmed from a cryptographic implementation flaw in Ed25519 nonce derivation that removed the secret input, enabling offline private key recovery from public Cardano transaction data.

Best Security Auditor for Web3

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

BlockSec Audit