Note:

This was reported to Zora but the contract in question is depreciated.

Link to the report.

TLDR

Zora’s built-in NFT marketplace lets operators accept bids using any ERC20 token. A malicious operator can exploit this by creating a custom ERC20 token that triggers external marketplace interactions during transfer. This allows the operator to sell an NFT to a buyer on another marketplace legitimately, then immediately steal the NFT back using Zora’s transfer logic, leaving the buyer empty-handed while keeping both the NFT and payment.

details.

Zora’s NFT marketplace is designed with flexibility in mind, allowing users to trade NFTs using any arbitrary ERC20 token. While flexible, this design carries implicit risks. Specifically, Zora’s marketplace does not properly account for scenarios where a malicious ERC20 token might execute custom logic during the bid finalization step, resulting in unintended state changes.

In simpler terms, Zora’s marketplace assumes ERC20 token transfers or approval calls are passive operations. However, a malicious operator can create custom ERC20 tokens containing active logic (hooks) that interact with external marketplaces, manipulating NFT ownership states mid-transaction.

Step 1: NFT Listing and Bidding (External Marketplace)

     • An operator mints a Zora NFT.

     • The operator lists this NFT on an external marketplace (e.g., OpenSea).

     • A customer sees the NFT and places a bid on the external marketplace.

Step 2: Malicious ERC20 Token Setup (Zora Marketplace)

     • The operator creates a custom ERC20 token under their complete control.

     • Using Zora’s built-in marketplace, the operator places a bid on his own NFT using this malicious ERC20 token.

Step 3: Initiating the Exploit (Accepting Malicious Bid)

     • The operator accepts his malicious bid via Zora’s marketplace.

     • This triggers Zora’s internal _finalizeTransfer() function to transfer the NFT.

Step 4: Malicious Logic Executes During Transfer

     • During _finalizeTransfer(), Zora’s marketplace invokes the malicious ERC20 token’s logic.

     • This custom ERC20 logic interacts with the external marketplace, automatically accepting the legitimate customer’s bid from Step 1.

     • The NFT is transferred from the operator to the customer, and payment is transferred to the operator.

Step 5: YOINK

     • Execution context now returns to Zora’s marketplace after the external sale.

     • Zora’s marketplace incorrectly assumes the NFT is still held by the operator. Due to this assumption, the marketplace proceeds to transfer the NFT from the customer to the operator.

Final Outcome:

     • The customer loses ownership of the NFT they purchased.

     • The operator retains both the customer’s payment and the NFT itself.

Note: The following is a fictionalized story of an out-of-scope report that I submitted to Foundation via Immunefi. The report is considered technically true but out of scope in part because of the belief that loss of reputation will prevent operators from using this exploit.

I remember the day I decided to resell my NFT on Foundation like it was yesterday. The piece was a rare digital sculpture by a once-respected creator. I’d purchased it months earlier for a nice amount, believing in the artwork’s long-term value. It had since appreciated, and I was excited to finally cash in. But when the time came, I found myself in a baffling position: I got nothing. Not a single ETH. Not one wei. All the proceeds slipped right through my hands and into the creator’s wallet.

It didn’t make sense. I was no newbie to NFTs—surely I hadn’t misunderstood something so fundamental. I had sold other NFTs before, and they’d been straightforward: I list, buyer pays, I get my cut, the creator gets their royalty. But this time, everything looked correct on the surface… until my payout never appeared. I decided to investigate. And that’s where my journey down the rabbit hole began.

Setting the Stage

After my sale closed, I waited for the transaction confirmations and the usual notifications. Except the familiar chime of incoming ETH never arrived. I checked my wallet’s balance: unchanged. Confused, I hopped onto Etherscan to follow the transaction trail. The buyer’s payment had gone through. The contract had processed the sale. The platform fees were taken out. And then, according to the transaction logs, my portion of the revenue was sent directly to the creator.

I stared at the transaction details, perplexed. Why in the world would the creator receive the entire sum from what should have been a secondary sale? Sure, creators get royalties, but not everything. Had I clicked the wrong button? Set my sale price incorrectly? I replayed the listing process in my head, but it all seemed normal.

Diving Into the Contracts

With no other leads, I turned to the code. Foundation, like many NFT marketplaces, uses smart contracts that are public on the blockchain. I knew how to look at verified code on Etherscan, so eventually I pulled up the MarketUtils contract. Browsing through the code, I found the part where the fees were calculated—the function that determined how to split the sale price between me (the seller) and the creator.

Then I saw something that made me do a double-take. There, in the logic, was a snippet that felt like a hidden booby trap:

if (creatorRecipients[i] == options.seller) {

// If the seller is any of the recipients defined, assume a primary sale

creatorRev += sellerRev;

sellerRev = 0;

}

Wait, what? This line meant that if my address—the seller’s address—appeared in the list of “creatorRecipients,” the code would treat the sale as if it were a primary sale. In a primary sale, the original creator is supposed to get almost everything less the platform fees. But I wasn’t the original creator. I was a secondary collector, trying to flip a piece on the secondary market. So why was my address popping up in that list?

A Suspicious Override Contract

I dug deeper. Foundation uses a royalty registry that allows creators to override default royalties with their own custom logic. This can be handy in a lot of legitimate scenarios—maybe a collective of artists shares revenue, or a charity receives part of the profits. But if a creator can add me, the seller, to that list of recipients, what then?

According to the code, if I’m listed as a creator recipient, the marketplace thinks it’s the first time this NFT is being sold. Suddenly, my rightful seller’s payout vanishes, merged into the creator’s pot.

As I followed the chain of contracts and calls, I discovered the culprit: the creator had registered an override contract that specifically listed my address as a “creator recipient.” That was bizarre, because I had no relationship with them. It looked like pure sabotage. And to ensure maximum mischief, they had cranked the creatorShares array so high that the code defaulted to paying only the first recipient in that list—which just so happened to be themselves.

Finding the Smoking Gun on Etherscan

I pulled up the override contract on Etherscan. It wasn’t well-known, had few interactions, and looked suspiciously like a bespoke trap. Inside, I could see the code logic specifying me as a recipient. My address, right there in black and white, lumped into the creator’s payout group.

I traced a few transactions and noticed how the contract was toggled on and off. The creator had set it up before my sale. Then, after the sale was done, they reverted to the original royalty setup. If someone came snooping later, they might never spot the scam unless they timed it just right.

To the outside world, it would appear as though the platform itself had made a deliberate decision to funnel all funds to the creator. But in reality, it was the code’s design interacting with malicious data provided by the creator’s override. Foundation’s marketplace logic had a loophole—one that let the creator manipulate a situation so that my address was treated as if I were the original artist, effectively zeroing out my cut.

A Quiet Acceptance

Armed with this information, I reached out to Foundation. I expected outrage, concern, or at the very least a swift patch. Instead, they seemed oddly unbothered. They considered the exploit “acceptable design.” According to them, the logic was working as intended: if a creator provides malicious data, that’s on the creator’s conscience, not the platform’s responsibility.

I gaped at my screen, incredulous. This was a blueprint for robbery, and they were okay with it, reasoning that a malicious creator would damage their reputation. But what about collectors like me who had just been robbed blind? Reputation damage doesn’t refill my empty wallet.

Reflections on a Harsh Lesson

As I sat back, I realized how vulnerable secondary sellers like me could be. I had stumbled into a hidden pitfall that most users probably never consider. When we trust platforms, we assume they protect both buyers and sellers from malicious actors. But in this case, the platform’s own fee logic and overrides combined into a perfect storm that let the creator siphon off what should have been my legitimate earnings.

A critical vulnerability was identified in both Async Art’s NFTAuction and SuperRare’s SuperRareAuctionHouse contracts. The former had approximately ~30k at risk, while the latter faced a potential loss of ~430k. Funds in both protocols remain secure. I reached out to Async through Discord and SuperRare via the SEAL 911 service.

Root Causes:

1. Doesn’t account for non-standard NFTs deviating from the ERC-721 specification.

2. Lacks the ability to differentiate between auctions.

3. Absence of validation ensuring that the currency in a bid matches the currency in the auction.

Async Art’s Vulnerability & Exploit:

Observations:

1. In Async’s NFTAuction contract, a seller can create an auction with a custom NFT and subsequently withdraw that NFT during the auction’s duration, then start another auction using the same NFT. This action results in the previous auction being superseded.

2. A bidder can bid on an NFT without it being actively auctioned. The contract doesn’t check the currency provided by the bidder during bid acceptance, necessitating sellers to be cautious when accepting bids.

My observations made me wonder if it would be possible to drain the contract of its ETH/ERC20s and it turns out that one can. Let’s see how.

One can use a custom NFT and valueless ERC20 to drain the NFTAuction contract of all its ETH. One does this by creating a sale using a valueless ERC20, an ERC20 one created, as the token, and a custom NFT one created as the NFT for sale. After the transaction to create the sale finishes one bids on his own NFT. The valueless ERC20s are sent to the contract and one is recorded as the highest bid. The sale price is greater than one’s bid. The bid price matches the amount one wants to withdraw from the NFTAuction contract. After the bid transaction finishes one calls the create sale function. Now the modifier should prevent one from doing this and in a standard NFT contract it would, however, the custom NFT one created shows one as the owner of the NFT. This allows one to pass new values to the sale. This time one sets the token to address(0) which is ETH. One also sets the buyNow price to the bid price. When the create sale function sees that the highestBid matches the buy now price it sends the bid price to one and the custom NFT.

After confirming this exploit with a Proof of Concept (PoC), I notified Async. Their team, leveraging my PoC, successfully secured ~30k worth of ETH, considering the NFTAuction is non-upgradable.

SuperRare’s Vulnerability & Exploit:

Upon reviewing SuperRare’s code, I noticed striking similarities to the aforementioned Async vulnerability.

Observations:

Instead of creating a valueless ERC20 one has to use an approved ERC20. This is important since this is the crux of the exploit. Fortunately, SuperRare uses its own RARE token which one can easily acquire. Instead of placing a bid and then creating an auction one converts an offer to an auction via convertOfferToAuction().

Once the offer is converted to an auction one can call the configureAuction() passing in similar parameters as one did when calling convertOfferToAuction() except one passes ETH as currency instead of RARE. This overwrites the previous auction created by the convertOfferToAuction() call but doesn’t overwrite the bid created in convertOfferToAuction(). When the auction ends one calls endAuction() and since endAuction() doesn’t verify that the currency in the bid matches the currency in the auction one receives the balance of ETH in SuperRareBazaar. Three addresses are used for this exploit; bidder, exploiter, and exploiter1.

Exploit Flow:

1. Operator creates custom NFT and mints to exploiter address.

2. From the bidder’s address, the Operator places an offer on said NFT using the SuperRare token as currency.

3. From the exploiter’s address, the operator converts the offer to an auction. This creates the first auction. The custom NFT ignores the transferFrom call since it comes from SuperRareBazaar.

4. The operator transfers the NFT from exploiter to exploiter1.

5. From exploiter1 he configures the auction using similar parameters except he uses ETH instead of SuperRare’s RARE token as currency. This overwrites the previous auction but doesn’t overwrite the bid that was created when the offer was converted to an auction.

6. Once the auction ends the operator calls endAuction() from any address he owns and receives about ~211.16 ETH or $315,881. This leaves the contract with about ~0.000749ETH or $1.25.

After validating this vulnerability using a local PoC and noticing the contract was active with ~500k at risk, I reached out to SuperRare. Despite initial communication challenges, the SEAL 911 service provided the necessary bridge to connect with SuperRare’s team. They promptly rectified the vulnerability and deployed the necessary fixes.

Links To Reports:

AsyncArt:

AsyncArt

SuperRare:

SuperRare