Expired NFT Marketplace, Unexpired Risk: Magic Eden Users Face Lingering Exploit from Old Trading Contract

Even after a marketplace closes, the digital permissions it once granted can keep operating — and that is precisely the situation facing former users of Magic Eden’s Ethereum-compatible trading platform.

Magic Eden, once the dominant NFT marketplace on Solana and later a multichain player, shuttered its EVM marketplace in early 2026 after dropping Ethereum and Bitcoin support in February of that year. But a vulnerability in the underlying smart contract it once used to settle trades has resurfaced, putting certain NFTs that changed hands on that platform between February and October 2024 at risk of theft.

The flaw sits in Payment Processor V2, a trading contract built and maintained by Limit Break. When Magic Eden adopted this contract to handle Ethereum-compatible transactions, it inherited a mechanism that allowed the contract to move tokens on behalf of users — a standard feature in NFT marketplaces known as an “approved for all” permission. Once granted, that permission does not expire. It persists indefinitely unless the user manually revokes it.

That persistence is what turned a dormant contract into an active liability. Even though Magic Eden stopped using the contract in October 2024 and shut down the marketplace entirely months later, anyone who had previously listed or traded an NFT on the platform may still have an open approval sitting on-chain, invisible unless checked.

An attacker identified the vulnerability and began exploiting it, targeting specific high-value collections. According to Yuga Labs Vice President of Blockchain 0xQuit, the stolen assets included 10 Meebits, 50 Otherdeeds, 10 World of Women NFTs, and 235 Desperate ApeWives.

Magic Break’s Payment Processor V3 contained the same flaw, and the company was able to pause that version. But V2 — the one Magic Eden actually used — could not be paused, because no single party held the authority to do so. With no kill switch available, a whitehat rescue operation became the only viable remedy.

0xQuit coordinated that operation, systematically identifying vulnerable NFTs and transferring them to secure wallets before the attacker could claim them. The effort recovered 23,155 NFTs valued at more than $5.7 million. Owners will be able to reclaim their assets, but only after they manually revoke the V2 contract’s approvals on Ethereum, Polygon, and Base — the three networks where the contract operates. Tools such as Revoke.cash can facilitate this process.

There is a significant caveat, however. Revocation prevents future unauthorized transfers, but it does nothing to recover tokens that have already been moved. In this case, 660 wrapped Ethereum (WETH) — exposed through a reverse variant of the exploit — could not be rescued in time and remain lost.

Magic Eden stated that no currently active listings on its platform were affected. The company’s own warning focused entirely on historical activity on its now-defunct EVM marketplace.

This episode underscores a broader structural issue in the NFT ecosystem: the tools that power trading are often separate from the platforms that host them, and vulnerabilities in infrastructure can outlive the interfaces users relied on. A marketplace may shut down, but the smart contracts it deployed or adopted continue executing on the blockchain, carrying with them whatever permissions users once granted.

For anyone who traded NFTs on Magic Eden’s EVM marketplace during the affected window, the practical step is straightforward but urgent: check approvals on Ethereum, Polygon, and Base, and revoke any lingering permissions tied to Payment Processor V2. Waiting carries risk — the exploit is known, and the window for safe recovery narrows as more assets remain exposed.

The timing is uncomfortable for the broader crypto industry. Just a day before Magic Eden’s warning, hackers stole more than $380 million in Ethereum and other digital assets from the Bitget exchange, marking the largest crypto breach of 2026 so far. Together, the two incidents highlight a sector still grappling with both infrastructure-level vulnerabilities and exchange-level security failures.