NFT (ERC-721) Smart Contract Security Pitfalls

Updated 2026-06-18 · VRF7 Security Guides

ERC-721 contracts power billions of dollars in NFT assets, yet many deployments ship with exploitable flaws that range from reentrancy in the mint function to trivially bypassable royalties. Unlike fungible tokens, NFTs carry per-token state — ownership, metadata URIs, royalty records — that creates a larger attack surface than a typical ERC-20. This guide walks through the five most consequential vulnerability classes in NFT contracts, shows what vulnerable and corrected code looks like, and explains how each class is typically detected by automated analysis tools.

1. Reentrancy via onERC721Received in safeMint

OpenZeppelin's _safeMint calls onERC721Received on the recipient if it is a contract. This callback is executed after the token is assigned to the recipient but potentially before state that limits minting is updated. An attacker can deploy a contract whose onERC721Received re-enters the mint function, draining the remaining supply or paying for far fewer tokens than they receive.

Vulnerable pattern

// VULNERABLE: counter updated after _safeMint
function mint(uint256 quantity) external payable {
    require(msg.value == quantity * PRICE, "wrong value");
    for (uint256 i = 0; i < quantity; i++) {
        _safeMint(msg.sender, _nextTokenId++);
    }
    totalMinted += quantity; // too late
    require(totalMinted <= MAX_SUPPLY, "sold out");
}

Fixed pattern

// FIXED: checks and state updates before _safeMint
function mint(uint256 quantity) external payable {
    require(msg.value == quantity * PRICE, "wrong value");
    require(totalMinted + quantity <= MAX_SUPPLY, "sold out");
    totalMinted += quantity;          // update first
    uint256 startId = _nextTokenId;
    _nextTokenId += quantity;
    for (uint256 i = 0; i < startId + quantity; i++) {
        _safeMint(msg.sender, startId + i - startId); // no re-entrancy window
    }
}

The canonical defense is the checks-effects-interactions pattern: validate inputs, write all state changes, then trigger external calls. Adding a nonReentrant modifier from OpenZeppelin's ReentrancyGuard is a reliable safety net when the call graph is complex. For a deeper treatment of reentrancy mechanics, see Reentrancy Attacks in Solidity: How They Work and How to Prevent Them.

2. Mint Supply and Per-Wallet Limit Bugs

Supply cap enforcement is among the most commonly miscoded invariants in NFT contracts. Three mistakes appear repeatedly in production deployments.

Integer overflow in supply check

Before Solidity 0.8, additions could silently wrap. Even on 0.8, using unchecked blocks inside mint loops for gas optimisation can reintroduce overflow. Always perform the cap comparison outside any unchecked scope.

Off-by-one errors

// VULNERABLE: allows MAX_SUPPLY + 1 tokens
require(_nextTokenId < MAX_SUPPLY, "sold out");

// FIXED:
require(_nextTokenId < MAX_SUPPLY, "sold out"); // if IDs are 0-indexed
// or equivalently:
require(totalMinted + quantity <= MAX_SUPPLY, "sold out");

Per-wallet limits stored in mappings that are trivially bypassed

Storing mint counts in mapping(address => uint256) public minted and checking minted[msg.sender] provides no protection against a contract that mints to a fresh address on every call. For allowlist phases this is usually acceptable; for public sales with hard per-wallet caps, consider allowlist signatures or Merkle proofs instead of on-chain address tracking.

3. Metadata and URI Manipulation

NFT value is often inseparable from its metadata. Two distinct problems arise here.

Mutable base URI controlled by an owner key

A contract that exposes setBaseURI(string memory uri) external onlyOwner lets the deployer silently replace every token's image and attributes after sale. Buyers have no on-chain guarantee that the metadata they purchased is permanent. If post-launch updates are genuinely needed, consider emitting events on every change so the modification is transparent on-chain, or use an immutable IPFS CID frozen at reveal time.

tokenURI returning attacker-controlled data

// VULNERABLE: no token existence check
function tokenURI(uint256 tokenId) public view override returns (string memory) {
    return string(abi.encodePacked(baseURI, tokenId.toString()));
}

// FIXED: revert for non-existent tokens
function tokenURI(uint256 tokenId) public view override returns (string memory) {
    require(_exists(tokenId), "URI query for nonexistent token");
    return string(abi.encodePacked(baseURI, tokenId.toString()));
}

Returning a URI for an unminted token ID exposes integrations and marketplaces to spoofed metadata before a token is legitimately created.

4. Royalty Bypass and EIP-2981 Misimplementation

EIP-2981 provides a standard royaltyInfo(uint256 tokenId, uint256 salePrice) function that marketplaces are expected to honour, but there is no enforcement mechanism on-chain. Contracts must not mistake EIP-2981 registration for royalty collection; a marketplace can simply ignore the signal.

Arithmetic error in royalty calculation

// VULNERABLE: integer division truncates, result is effectively 0 for small sales
return (receiver, salePrice / 100 * royaltyPercent);

// FIXED: multiply before divide
return (receiver, (salePrice * royaltyPercent) / 100);

Royalty recipient set to address(0)

If the royalty receiver is left as the zero address — often because the constructor did not initialize it — royalty payments sent on-chain (e.g., by contracts that do enforce EIP-2981) are burned. Always validate that _royaltyReceiver != address(0) in the constructor and in any update function.

5. Access Control on Mint and Administrative Functions

Unrestricted or misconfigured access control on minting functions is one of the highest-impact NFT vulnerabilities. Common failure modes include:

• A mint function with no onlyOwner or payment check, allowing anyone to mint unlimited tokens for free.
• Role-based access control where DEFAULT_ADMIN_ROLE is granted to address(0) in the constructor, making the role permanently unrevokable.
• Owner renouncement without transferring critical roles first, permanently bricking administrative functions.
• A public setMintEnabled or setPublicSaleActive function missing an access modifier entirely — a common copy-paste error when adapting boilerplate.

// VULNERABLE: no access modifier
function setPublicSaleActive(bool active) external {
    publicSaleActive = active;
}

// FIXED:
function setPublicSaleActive(bool active) external onlyOwner {
    publicSaleActive = active;
}

For a systematic breakdown of how access control failures propagate across contract systems, see Access Control Vulnerabilities in Smart Contracts. Many of the same patterns that affect ERC-20 contracts apply equally here; the How to Audit an ERC-20 Token Contract guide covers role hierarchies and privilege escalation paths worth reviewing alongside NFT-specific concerns.

6. On-Chain Randomness Pitfalls

Many NFT projects use randomness to assign rarity at mint time or to conduct lottery-style allowlist draws. Using predictable on-chain values as entropy sources is reliably exploitable.

Block-based entropy

// VULNERABLE: miner/validator can influence blockhash and timestamp
uint256 randomIndex = uint256(
    keccak256(abi.encodePacked(block.timestamp, block.prevrandao, msg.sender))
) % MAX_SUPPLY;

A validator proposing a block can observe that a given seed produces an unfavourable token assignment and simply withhold the block, trying again with the next slot. block.prevrandao (post-Merge) is significantly harder to manipulate than the pre-Merge block.difficulty, but it is still a single validator-observable value and should not be used as the sole entropy source for high-value randomness.

Commit-reveal schemes

A two-transaction commit-reveal forces the randomness to be committed before the outcome is determined. The user submits a hash of their secret in transaction one; in transaction two (after some block delay) they reveal the secret, which is mixed with a block hash not yet known at commit time. The weakness is that a user can simply abandon a reveal if the outcome is unfavourable, so commit-reveal works best when abandonment carries a cost, such as forfeiting a deposit.

Verifiable Random Functions

Chainlink VRF provides cryptographically verifiable randomness that cannot be predicted or manipulated by any single party. It introduces latency and LINK token costs, but for randomness that determines token rarity or award distribution in a high-value mint, it is the appropriate tool. The core pattern is to request randomness in one transaction and fulfill it in a callback, keeping the fulfillment callback free of additional external calls to avoid reentrancy in that path.

How Automated Tools Detect These Issues

Static analysis tools catch a meaningful portion of the vulnerabilities described above. Slither identifies reentrancy patterns and missing access modifiers. Semgrep rules flag dangerous entropy sources such as block.timestamp used in randomness. Solhint enforces visibility and modifier conventions that surface unprotected administrative functions. Mythril and SMTChecker can model integer overflow paths and verify arithmetic invariants symbolically. Echidna, as a fuzzer, is particularly effective at finding supply-cap off-by-one errors by generating adversarial mint sequences at the boundary of MAX_SUPPLY.

No automated tool catches every vulnerability — logic errors unique to a project's tokenomics or subtle cross-contract interactions typically require manual review — but running a full suite before deployment eliminates the most common and most costly mistakes. You can run an automated scan on VRF7 to check your ERC-721 contract against all of these tools in parallel, with each finding attributed to the specific tool that produced it.

Summary

• Apply checks-effects-interactions and nonReentrant to any function that calls _safeMint.
• Validate supply caps before any state mutation or external call; keep supply arithmetic outside unchecked blocks.
• Freeze metadata at reveal by pointing to an immutable IPFS CID, or emit events on every URI change to maintain transparency.
• Implement EIP-2981 correctly — multiply before dividing, and validate the receiver address in the constructor.
• Apply and audit access modifiers on every state-changing function, including toggle switches for sale phases.
• Use Chainlink VRF for rarity assignment or any other randomness with meaningful financial consequences; treat block variables as weak entropy only.