The NFT space has matured beyond profile pictures and speculative trading. NFTs now represent gaming assets, real-world assets (RWAs), memberships, identity credentials, and financial instruments. With this expanding utility comes expanding attack surface.
Most NFT security discussions focus on phishing and scam projects. The deeper risks are in the smart contracts themselves.
The NFT Attack Surface
1. Minting Vulnerabilities
criticalMinting is the most security-sensitive phase of any NFT project:
Whitelist bypass
Merkle proof verification is incorrect or the root can be changed by the owner. Attacker mints without being whitelisted, or mints more than their allocation.
Reentrancy during mint
The mint function makes an external call (ERC-721's _safeMint triggers onERC721Received). If minting state isn't updated first, the callback can re-enter and mint additional tokens.
Signature replay
Off-chain signatures authorizing mints can be replayed if the nonce isn't tracked on-chain. Attacker uses a valid signature to mint multiple times.
Max supply bypass
Race condition between mint calls allows total supply to exceed the intended maximum. Or the check uses less-than instead of less-than-or-equal.
The reentrancy risk during minting connects to the patterns we covered in Reentrancy Attacks Explained — ERC-721's _safeMint is a common source of callback-based reentrancy.
⚠️_safeMint Is Not Safe
Despite the name, _safeMint is less safe than _mint from a reentrancy perspective. It calls onERC721Received on the recipient, which triggers an external call. Use _mint when the recipient is a known EOA, or add ReentrancyGuard when using _safeMint.
2. Metadata Manipulation
highMetadata Attack Vectors
Centralized metadata
If tokenURI points to a centralized server (https://api.project.com/metadata/1), the project owner can change any token's image, attributes, and rarity after mint — a rug pull vector.
Unrevealed manipulation
Pre-reveal, all tokens point to the same placeholder. If the reveal mechanism is predictable (sequential assignment, predictable randomness), insiders can identify rare tokens before reveal and buy them.
IPFS mutability
IPFS content is addressed by hash, so it's immutable. But if the contract stores an IPFS gateway URL instead of the CID directly, the gateway can serve different content. Only on-chain CIDs are truly immutable.
3. Royalty Enforcement Issues
mediumERC-2981 defines a royalty standard, but enforcement is voluntary — marketplaces can (and some do) ignore it:
- Bypass via direct transfer — Selling via a separate payment contract and transferring the NFT directly bypasses marketplace royalty enforcement
- Wrapper contracts — Wrapping an NFT in a new contract that doesn't implement royalties
- Off-chain deals — Peer-to-peer trades arranged off-chain with no royalty payment
4. Approval Abuse
highNFT approvals are a major attack vector:
setApprovalForAll grants unlimited access
When a user approves a marketplace to trade their NFTs, they typically call setApprovalForAll — granting the marketplace access to ALL their NFTs in that collection, not just the one being listed
Malicious contract exploits approval
If the approved contract (or a contract it delegates to) has a vulnerability, an attacker can transfer any of the user's approved NFTs without further permission
Phishing for approvals
Malicious websites prompt users to sign setApprovalForAll transactions disguised as minting or claiming actions. Once approved, the attacker drains all NFTs.
5. Marketplace-Specific Vulnerabilities
Marketplace Security Risks
Signature-based order manipulation
Marketplaces use off-chain signatures for listings. If the signature doesn't include all relevant parameters (token ID, price, expiration, specific marketplace address), orders can be manipulated or replayed.
Stale listing exploitation
User lists an NFT for 1 ETH, buys it back, and forgets to cancel the listing signature. Later the floor price rises to 10 ETH. The old 1 ETH listing signature is still valid and can be executed.
Bid manipulation
Off-chain bids that don't verify the token's current state can be accepted after the token's attributes have changed (downgraded, transferred, or modified).
Security Checklist for NFT Projects
Minting
ReentrancyGuard on mint, verify Merkle proofs, track signature nonces, enforce supply cap atomically
Metadata
Use IPFS/Arweave with on-chain CIDs. Commit-reveal for fair launches. No centralized metadata endpoints.
Approvals
Implement ERC-721C or similar operator filtering. Educate users about approval risks.
Audit
Full security audit of all contract logic — especially minting, reveal, and staking mechanisms
As we outlined in our Solidity Security Patterns handbook, the checks-effects-interactions pattern and proper access control are essential for every NFT contract — not just DeFi.
ℹ️NFTs Are Smart Contracts First
The security challenges of NFTs are fundamentally smart contract security challenges. Every vulnerability class from our DeFi audits — reentrancy, access control, precision issues — applies equally to NFT contracts. Don't let the "art" framing make you forget these are financial smart contracts.
Launching an NFT project? Our Smart Contract Auditor tests minting logic, metadata integrity, approval patterns, and marketplace integrations. For complex NFT ecosystems (gaming, RWAs, DeFi-integrated), our expert review provides comprehensive security analysis. Get audited.