Magic Eden avait cessé d'utiliser Payment Processor V2 en octobre 2024. Sa marketplace EVM elle-même a ensuite été fermée au premier trimestre 2026. Pourtant, le 25 septembre, la société a dû rappeler d'anciens utilisateurs à une opération très actuelle : révoquer des permissions accordées jusqu'à deux ans auparavant.

Le problème ne venait pas de nouvelles annonces de vente laissées en ligne. Magic Eden affirme qu'aucun listing actuellement actif n'a été touché. Le risque se trouvait plus bas, dans les approvals onchain accordées lorsque les utilisateurs avaient interagi avec Payment Processor V2.

Annuler une annonce ne retire pas forcément la permission du smart contract

Sur un NFT EVM, une approval peut donner à un contrat le droit de déplacer des actifs détenus par un wallet. Une autorisation de type « approved for all » est particulièrement large : tant qu'elle n'est pas révoquée par une transaction onchain, elle peut continuer d'exister indépendamment de l'interface qui l'avait demandée.

C'est la différence qui compte ici. Une marketplace peut masquer une annonce, arrêter d'utiliser un protocole puis fermer tout son produit EVM. La permission inscrite sur Ethereum, Polygon ou Base n'en sait rien. Elle reste là jusqu'à ce que son propriétaire la révoque ou qu'une autre mécanique du contrat la rende inutilisable.

Magic Eden indique que les utilisateurs ayant listé ou échangé des NFT via son marché EVM entre approximativement février et octobre 2024 peuvent être concernés. L'entreprise leur demande de retirer les approvals de Payment Processor V2 sur Ethereum, Polygon et Base.

L'attaque a d'abord touché plusieurs collections connues

Selon 0xQuit, vice-président blockchain de Yuga Labs, un attaquant a exploité la vulnérabilité pour prendre 10 Meebits, 50 Otherdeeds, 10 NFT World of Women et 235 Desperate ApeWives. Ce n'est qu'ensuite que l'étendue des permissions encore exploitables est devenue évidente.

Payment Processor V2 est un protocole de trading NFT développé et maintenu par Limit Break. Sa documentation prévoit notamment les transferts de NFT nécessaires au règlement des ventes et offres. Cela suppose naturellement que le contrat dispose des autorisations nécessaires pour déplacer les actifs au moment d'une transaction.

La vulnérabilité a rendu précisément cette capacité dangereuse pour des approvals restées actives. Les détails complets de la cause racine n'ont pas encore été publiés dans un post-mortem technique officiel suffisamment détaillé pour attribuer chaque étape de l'exploitation. Ce qui est confirmé publiquement est l'existence de la faille et l'exposition des anciennes permissions.

23 155 NFT ont été déplacés avant les attaquants

Une opération white-hat a alors utilisé la même surface de transfert pour mettre les actifs vulnérables hors de portée des attaquants. 0xQuit affirme que 23 155 NFT, valorisés à plus de 5,7 millions de dollars, ont ainsi été sécurisés.

Vu de l'extérieur, l'opération avait tout pour ressembler au problème lui-même : des milliers de NFT ont soudainement quitté les wallets de leurs propriétaires, parfois à travers des transactions affichées comme des ventes à zéro ETH. La différence se trouvait dans l'adresse de destination et l'objectif du transfert.

Les propriétaires doivent maintenant révoquer les approvals vulnérables avant de pouvoir récupérer les NFT mis à l'abri. Les déplacer immédiatement vers les mêmes wallets sans supprimer l'autorisation reviendrait à les remettre sous la portée du contrat problématique.

Limit Break a pu suspendre Payment Processor V3, qui partageait selon 0xQuit la même faiblesse. V2, en revanche, ne pouvait pas être simplement mis en pause, ce qui explique la nécessité de déplacer les actifs eux-mêmes.

Le problème ne s'arrêtait pas aux NFT

Pendant l'intervention, l'équipe a identifié un mécanisme apparenté permettant d'exposer du WETH dans le sens inverse. 0xQuit a indiqué qu'environ 660 WETH se trouvaient à risque et que l'opération n'avait pas réussi à les récupérer à temps.

Cette partie doit être formulée avec prudence : les communications disponibles établissent l'exposition des 660 WETH et l'échec de leur récupération par l'équipe white-hat, mais elles ne fournissent pas encore un bilan technique complet permettant de reconstruire proprement le sort de chaque unité concernée.

Magic Eden continue de son côté à évaluer l'étendue de l'incident avec Limit Break. Sa recommandation immédiate est plus simple que le post-mortem à venir : les anciens utilisateurs de la marketplace EVM doivent contrôler et révoquer les approvals de Payment Processor V2 sur les réseaux concernés.

Les approvals oubliées sont une dette technique qui appartient au wallet

L'incident est intéressant parce qu'il survit à presque tout ce qui, dans une application web traditionnelle, aurait signifié « fin du produit ». Magic Eden avait changé de stratégie, abandonné Payment Processor V2 puis fermé sa marketplace EVM. Le contrat et les autorisations des utilisateurs continuaient pourtant d'exister sur les chaînes.

Un service centralisé peut désactiver un compte ou supprimer un ancien jeton d'accès côté serveur. Une approval blockchain fonctionne différemment : elle appartient à l'état onchain du wallet. Le fournisseur qui a affiché le bouton « approve » n'a pas nécessairement la capacité de revenir plusieurs années plus tard et d'effacer cette permission à la place de l'utilisateur.

C'est une propriété utile pour des protocoles sans permission, mais elle produit une forme de dette de sécurité très particulière. Les applications disparaissent plus vite que leurs contrats, et les interfaces évoluent plus vite que les autorisations déjà signées.

Dans ce cas, il aura fallu une vulnérabilité du Payment Processor pour rappeler que quitter une marketplace n'équivalait pas à révoquer ce qu'elle avait autrefois le droit de faire.