Magic Eden stopped using Payment Processor V2 in October 2024. It later shut down its EVM marketplace in the first quarter of 2026. On September 25, however, some of the permissions created during that old integration were still very much alive.

Magic Eden says no live listings were affected. The risk was sitting underneath the marketplace interface in onchain approvals that users had previously granted to the Payment Processor contract.

Removing the listing is not the same as removing the approval

An EVM NFT approval can authorize another contract to move assets from a wallet. With an approval-for-all permission, that authority can remain available until the owner explicitly revokes it onchain.

That creates an important separation between application state and blockchain state. A marketplace can hide an order, abandon an integration or shut an entire product down. None of those actions necessarily changes a permission that a user's wallet previously recorded on Ethereum or another compatible chain.

Magic Eden says people who listed or traded NFTs on its EVM marketplace from roughly February through October 2024 may be affected. It is advising those users to revoke Payment Processor V2 approvals on Ethereum, Polygon and Base.

The first exploit hit several recognizable NFT collections

According to Yuga Labs blockchain vice president 0xQuit, an attacker exploited the Payment Processor V2 bug to take 10 Meebits, 50 Otherdeeds, 10 World of Women NFTs and 235 Desperate ApeWives.

Payment Processor V2 is an NFT trading protocol developed by Limit Break. Its integration model requires the ability to move NFTs when marketplace orders are settled, which is why users had granted the contract transfer permissions in the first place.

The full root cause has not yet been documented in a sufficiently detailed official post-mortem to reconstruct every part of the exploit with confidence. What has been confirmed is that the V2 vulnerability made those lingering permissions dangerous.

White hats moved 23,155 NFTs out of reach

Once the wider exposure became clear, a white-hat operation used the available transfer path to secure vulnerable assets before additional attackers could reach them. 0xQuit says 23,155 NFTs worth more than $5.7 million were moved to safety.

Onchain, that rescue initially looked alarming in its own right. Thousands of NFTs were suddenly leaving hundreds of wallets, with some transactions appearing as zero-ETH Magic Eden sales. The destination and intent were the key difference: the assets were being held for return rather than taken for profit.

Owners must revoke the vulnerable approvals before reclaiming rescued NFTs. Returning them first would put the assets back into wallets where the same Payment Processor permission could still be active.

Limit Break was able to pause Payment Processor V3, which 0xQuit said contained the same bug. V2 could not simply be paused, leaving asset relocation as the practical containment method for the older contract.

A related path also exposed WETH

During the response, the team discovered that a similar exploit could operate in the opposite direction against wrapped ether. 0xQuit said roughly 660 WETH was at risk and that the white-hat effort was not able to recover it in time.

That point still needs careful wording. Public disclosures support the amount exposed and the failed rescue attempt, but a complete technical accounting of the affected WETH has not yet been published.

Magic Eden says it is continuing to assess the incident with Limit Break. Its immediate guidance is much simpler than the eventual post-mortem: former EVM marketplace users should inspect and revoke Payment Processor V2 approvals on the affected chains.

Dormant approvals are a form of wallet-level technical debt

The most useful part of this incident is how long the vulnerability's blast radius outlived the product that created it. Magic Eden had changed strategy, stopped using the processor and closed its EVM marketplace. The contracts and user permissions persisted.

A conventional online service can invalidate an old server token when it shuts down a feature. A blockchain approval belongs to the wallet's onchain state instead. The company that once displayed the approval button may not be able to erase it on behalf of every user later.

That persistence is useful for permissionless systems, but it also creates unusually durable security debt. Applications can disappear while their contracts remain reachable, and interfaces can be forgotten while old approvals stay valid.

Here, it took a Payment Processor vulnerability to make that old distinction expensive enough to notice again.