NFT protocol vulnerabilities in disclosed bug bounty reports

Minting, marketplace settlement and royalty enforcement — where signature handling and callback hooks do most of the damage.

Reports indexed
148
Total paid
$60k
Critical
0
Largest payout
$60k

NFT findings concentrate in three places: mint mechanics, marketplace order settlement, and the callback hooks the token standards mandate. Mint bugs are usually supply or allowlist accounting. Marketplace bugs are usually signature scope — an order that can be filled twice, cancelled ineffectively, or matched against a different asset than intended.

The `onERC721Received` and `onERC1155Received` hooks reintroduce reentrancy into contracts that would otherwise be safe, which is why so many NFT reports cross-reference the reentrancy category.

Randomness for reveals and trait assignment is the fourth recurring surface, and on-chain sources of it remain predictable in ways the write-ups spell out clearly.

What reviewers look for

  • Allowlist and supply accounting under concurrent mints
  • Marketplace orders fillable more than once or after cancellation
  • Receiver hooks re-entering mint or settlement logic
  • Predictable on-chain randomness for reveals or traits
  • Royalty enforcement bypassable through an alternate transfer path

Curated highlights

The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.

mediumSignature replayEVM-Solidity$60k

NFT marketplace signature does not bind to token id allowing order swap

An NFT marketplace implemented an off-chain EIP-712 order signing mechanism that failed to include the token ID within the signed struct hash. Because the token ID was accepted directly from unverified calldata during order execution, malicious actors could swap order parameters to fulfill trades using unintended token IDs from the same collection. This allowed attackers to acquire high-value collection items using floor-priced signatures or trade arbitrary assets under invalid terms.

NFT MarketplacecantinaMay 21, 2024Open
mediumLogic errorEVM-Solidity$0

Putty: An attacker can create a short put option order on an NFT that does not support ERC721 (like cryptopunk), and the user can fulfill the order, but cannot exercise the option

The Putty protocol incorrectly assumes that all NFT assets used as underlying collateral in options contracts support the full ERC-721 standard. By using a safeTransferFrom implementation that requires the onERC721Received callback, the protocol unintentionally renders certain legacy NFTs, like CryptoPunks, unexercisable. Attackers can exploit this by offering options on these incompatible assets, collecting premiums from users who are then unable to exercise their options or receive the underlying asset.

Puttycode4renaAug 7, 2026Open
mediumLogic errorEVM-Solidity$0

Putty: Overlap Between `ERC721.transferFrom()` and `ERC20.transferFrom()` Allows `order.erc20Assets` or `order.baseAsset` To Be ERC721 Rather Than ERC20

Putty protocol is vulnerable to a token standard confusion issue where ERC721 tokens can be submitted in place of ERC20 assets. Because both standards share similar transferFrom function signatures, the protocol successfully pulls the NFT into its custody. However, due to the incompatibility between ERC20-based withdrawal logic and the ERC721 standard, these tokens become permanently locked within the contract, resulting in a total loss of funds for the depositor.

Puttycode4renaAug 7, 2026Open
mediumReentrancyEVM-Solidity$0

Putty: The contract serves as a flashloan pool without fee

PuttyV2's fillOrder and exercise functions lacked reentrancy protections, allowing a malicious user acting as both maker and taker to re-enter the contract from a malicious base-asset transfer callback. That re-entry exercises a short call to pull real ERC20/ERC721 balances out of PuttyV2, deploy them for profit on other venues, and repay before fillOrder completes. Because the protocol's 3% option fee is assessed in the base asset—an attacker-controlled custom token—the attack amounts to free, unrestricted use of all assets held by the contract. Sponsor and judge acknowledged the validity, agreeing flashloans are a feature but fee evasion is a bug, with no easy mitigation beyond nonReentrant guards at a gas cost.

Puttycode4renaAug 7, 2026Open
highLogic errorEVM-Solidity$0

Putty: Create a short call order with non empty floor makes the option impossible to exercise and withdraw

The Putty options protocol suffered from a critical logic error where short call orders could be created with non-empty floor token arrays. This invalid state prevented takers from exercising their options and makers from withdrawing their deposited collateral after expiration, effectively bricking the funds involved in the order. Furthermore, this flaw could be exploited to grief other users by creating orders that conflict with the assets used in active, legitimate positions, leading to a permanent loss of access to those assets.

Puttycode4renaAug 7, 2026Open
mediumLogic errorEVM-Solidity$0

Putty: Malicious Token Contracts May Lead To Locking Orders

Putty lets a maker construct an option whose erc20Assets, erc721Assets, and floorTokens fields point at arbitrary token contracts. Because PuttyV2.exercise() performs external transfer calls to each of those addresses, a maker who controls one of those token contracts can flip it into a permanently-reverting state, making the option impossible to exercise for its entire life. Since the long position is already burned to 0xdead before the transfer step, a failed transfer permanently traps the position. A short maker benefits by freezing an option when the price moves against them, then re-enabling transfers once expiry or a favorable price arrives. The judge upheld the finding at Medium severity because a user only becomes exposed by voluntarily filling an option that already contains the malicious asset, and the sponsor chose to mitigate with UI warnings rather than a contract-level whitelist.

Puttycode4renaAug 7, 2026Open

All reports in this group

Vulnerability classes seen in this protocol type

Related protocol type pages