Limit Break Payment Processor V2: Stale Approvals + Forwarder Spoofing Drain $2.8M in NFTs

Attackers exploited a trusted-forwarder vulnerability in Limit Break's immutable Payment Processor V2 contract, abusing NFT approvals granted in 2024 to steal ~$2.8M across five EVM chains; white-hat 0xQuit rescued ~23,155 NFTs (~$5.7M) in a front-running rescue.

Root Cause

Limit Break's Payment Processor V2 (used by Magic Eden for EVM trades in 2024) relied on an ERC-2771-style trusted forwarder pattern for meta-transaction support. The contract derived the effective caller via a _msgSender() override that could be influenced by a malicious or compromised forwarder contract.

This is a variant of the 2023 ERC-2771 + Multicall3 vulnerability class: when a contract unconditionally trusts a forwarder's claimed msg.sender, an attacker who can manipulate the forwarder can impersonate any address that previously granted approvals to the processor. Victims had legitimately granted setApprovalForAll to PP V2 in 2024. Those approvals were never revoked and persisted years after the marketplace deprecated the contract.

Limit Break found the same forwarder weakness in Payment Processor V3 and paused it as a precaution. PP V2 is immutable—no on-chain patch is possible.

// Vulnerable pattern (conceptual)
contract PaymentProcessorV2 is ERC2771Context {
    // _msgSender() returns forwarder's injected address, not tx origin
    function executeOrder(
        address token,
        uint256 tokenId,
        address /* buyer */
    ) external {
        address buyer = _msgSender();  // spoofable via forwarder
        // Executes transfer using victim's existing setApprovalForAll
        IERC721(token).transferFrom(
            victim,   // attacker-injected via _msgSender spoofing
            attacker,
            tokenId
        );
    }
}

Attack Steps

Step	Action
1	Attacker enumerates wallets with live `setApprovalForAll` grants to PP V2 (granted ~2024)
2	Crafts forwarder call that injects victim address as `_msgSender()`
3	`executeOrder()` called impersonating victim; PP V2 reads victim's existing approval
4	NFTs transferred from victim wallet to attacker-controlled address
5	Exploitation spans Ethereum, Polygon, Base, Arbitrum, ApeChain
6	White-hat 0xQuit (Yuga Labs) identifies pattern; front-runs attacker, rescues ~~23,155 NFTs (~~$5.7M)
7	OpenSea flags and blocks >3,000 items from trading
8	Limit Break identifies same forwarder flaw in PP V3; pauses PP V3 as precaution

Impact

~$2.8M stolen in NFTs across five EVM chains
~$5.7M at risk; ~23,155 NFTs rescued by white-hat
Chains: Ethereum, Polygon, Base, Arbitrum, ApeChain
Exploit began approximately September 24, 2026; ongoing through ~October 20, 2026
The Sandbox: 37 LAND on Ethereum + 1,027 ASSETS from 47 Polygon wallets taken
PP V2 is immutable—revocation of approvals is the only defense for users

Lessons for Auditors

ERC-2771 trusted forwarder scope must be tightly controlled: The _msgSender() override is only safe if the set of permitted forwarder contracts is a small, audited, non-upgradeable set. Auditors must trace every path where _msgSender() diverges from msg.sender and verify the forwarder cannot be manipulated or called by arbitrary addresses.
Approval expiry for marketplace contracts: Contracts accepting setApprovalForAll for trading should implement time-bounded or platform-scoped approvals. Unlimited indefinite approvals survive protocol deprecation and remain exploitable for years.
Immutability compounds forwarder bugs: Upgradeable proxies permit patching; immutable contracts make user-side revocation the only remedy. Production contracts that hold or route asset approvals should include an emergency pause mechanism even if the rest of the contract is immutable.
Cross-version vulnerability propagation: When a vulnerability is found in V2, the same pattern often exists in V3 and later versions. Immediately audit all related contracts from the same codebase.