Magic Eden legacy approvals expose $5.7 million in NFTs to exploit

A vulnerability in Limit Break's Payment Processor V2 protocol exposed legacy approvals from Magic Eden's closed EVM marketplace, leading to an exploit that began on September 24, 2026. While attackers stole at least $2.8 million across multiple chains, a whitehat rescue operation led by Yuga Labs Vice President 0xQuit secured 23,155 NFTs worth over $5.7 million. On September 26, 2026, 0xQuit launched a reclaim site, requiring users to revoke their legacy approvals before recovering their assets.

Magic Eden legacy approvals

• ▪Magic Eden confirmed that no live listings on its marketplace were impacted by the Payment Processor V2 exploit that began on September 24, 2026
• ▪Magic Eden adopted Limit Break's Payment Processor V2 in 2024, stopped using Payment Processor V2 in October 2024, and closed its EVM marketplace in the first quarter of 2026
• ▪Although Magic Eden closed its EVM marketplace, active on-chain approvals granted by users in 2024 remained live, exposing their wallets to the Limit Break Payment Processor V2 exploit

The Payment Processor V2 vulnerability

• ▪A vulnerability in Limit Break's Payment Processor V2 contract allowed attackers to hijack NFTs and purchase worthless tokens using wallet balances
• ▪Because Limit Break's Payment Processor V2 contract cannot be paused or patched on-chain, the protocol remains vulnerable to exploits indefinitely
• ▪Limit Break paused its newer Payment Processor V3 contract on all networks except ApeChain, where it remains active until November 30, 2026

Revoking legacy approvals

• ▪Revoke.cash warned that canceling active marketplace listings or disconnecting wallets from websites does not deactivate on-chain smart contract approvals
• ▪Magic Eden and Revoke.cash urged users to revoke legacy approvals for Limit Break's Payment Processor V2 on Ethereum, Polygon, and Base to prevent future wallet exploits

Debatable claims

• ▪Whitehat researchers are justified in transferring user assets without consent to protect them from exploits
• ▪Developers should design all smart contracts with pause or upgrade mechanisms
• ▪Marketplaces bear primary responsibility for the security risks of legacy smart contract approvals
• ▪The current Web3 smart contract approval model is too dangerous for mainstream adoption