Thread by @0xCygaar

An explanation of the NFTTrader hack that resulted in millions of dollars worth of NFTs stolen 🧵:

(TLDR; combination of reentrancy + old approvals that were never removed)

The attack starts by calling the NFTTrader contract and creating a new "swap intent" (createSwapIntent).

Normally two lists are provided - a list of tokens that the swapper wants to give up, and a list of tokens to be received.

For this attack, the former list was empty.

The attacker also created the swap so that the receiver of the swap is also the attacker's address. Normally this value (addressTwo) should be the counter party (someone else).

The result is that both of the swap's parties are the same address - it's a self-swap.

The last important piece of info to note is that the swap includes an arbitrary NFT (a UniswapV3 LP position) alongside the actual stolen NFT.

This might seem random, but it's used to conduct the reentrancy exploit. This random NFT is always the first NFT in the swap.

After the swap intent is created, the attacker calls closeSwapIntent to initiate the transfer of assets.

The first asset to be swapped is the UniV3 NFT. The source and destination addresses of the transfer are both the attacker's address here.

safeTransferFrom is dangerous because it has a callback that's triggered after the transfer is done. This is what can lead to reentrancy attacks.

In our specific case, the safeTransferFrom is also called with data - this is where the victim's address is embedded.

The safeTransferFrom function is executed, which calls back into the attacker's contract with the victim's address.

The malicious contract then calls the NFTTrader contract's editCounterPart function.

Remember how the swap was originally a self-swap?

The attacker uses editCounterPart to change the counter party to the victim's address.

This is the first phase of the attack. The swap is now a swap between the attacker and the victim.

Now we go back to the original call context. The UniV3 NFT was just self-transferred, and the counter party (addressTwo) has been switched to the victim.

We then go to the next NFT to be transferred - the BAYC in this case.

Previously, the "from" value was the attacker's address. Now it's the victim's address.

The second critical part of the attack is that the victim had an old approval that allows the NFTTrader contract to transfer around the victim's BAYC NFTs.

That's what allows the safeTransfer to work. Had the user revoked approval to the NFTTrader contract, this attack could not have happened.

Unfortunately, the combo of reentrancy + old approvals led to NFTs being stolen.

The easiest way for this attack to have been prevented is if NFTTrader had a reentrancy guard on the editCounterPart function.

This would've prevented the malicious contract from changing the counter party during a swap.

The NFTTrader contract can be found here: .

The attacker's contract is here: .

I used and tenderly to trace through the exploit flow: .etherscan.deth.net/address/0x13d8…
etherscan.io/address/0xc446…
evm.storage
evm.storage/eth/0x1aaff86a…

In terms of action items - I would revoke all approvals to NFTTrader if you can.

Although if you could've been exploited, you definitely would've been exploited by now.

Looks like it's fixed now:

https://twitter.com/0xfoobar/status/1736065084294627576