Skip to content
low Token Standards No SWC entry CWE-703

Contract Cannot Receive ERC721/1155 (Locked NFTs)

SAFE-0216 Token Standards Checked automatically by the scanner
1

What goes wrong

A contract that holds NFTs (escrow, staking, marketplace) does not implement onERC721Received / onERC1155Received. Safe transfers into it revert, or NFTs sent via safeTransfer become stuck if a non-safe path was assumed.

2

The vulnerable pattern

proof of concept — how it is exploited
// staking.stake() pulls the NFT via safeTransferFrom
// vault has no onERC721Received -> the transfer reverts, staking broken;
// or a stuck NFT with no withdraw path.
3

How to fix it

the pattern that is safe
contract Vault is IERC721Receiver {
  function onERC721Received(address,address,uint256,bytes calldata) external pure returns (bytes4) {
    return IERC721Receiver.onERC721Received.selector;
  }
}
◆
Implement the receiver hooks in NFT-holding contracts.
4

Related vulnerabilities in Token Standards

SAFE-0053Unsafe / Unprotected Minting critical · Token Standards SAFE-0051Missing SafeERC20 / Non-Standard Token Handling high · Token Standards SAFE-0052Fee-on-Transfer / Rebasing Token Accounting Mismatch high · Token Standards SAFE-0055Burn Authorization / Burn-From Missing Checks high · Token Standards SAFE-0107Fee-on-Transfer / Rebasing Token Mis-Accounting high · Token Standards SAFE-0208Non-Standard ERC20 Return Value Not Handled high · Token Standards SAFE-0050ERC-20 Approval Race Condition medium · Token Standards SAFE-0054ERC-721/1155 Missing Receiver Validation (Safe Transfer) medium · Token Standards
← PreviousUnbounded / Unsanitised tokenURI Metadata
Check your own contract for this

The SaferICO scanner runs 201 detectors over your Solidity source, SAFE-0216 among them. Paste an address or the source itself — a small per-scan fee, shown before you sign, or unlimited on any plan.

Run the scanner See how it is attacked Read the docs