L’EIP-7702, la fonctionnalité d’Ethereum ajoutée avec la mise à jour Pectra, est l’outil qui a servi sur Binance 14, l’un des portefeuilles chauds touchés par le piratage de Binance, et les relevés de la blockchain montrent comment. Une seule transaction, à 20 h 20 min 59 s UTC le 29 octobre, portait 50 autorisations signées pour ce portefeuille. Une seule était valide. Le pillage a suivi 3 minutes 24 secondes plus tard, pour environ 2,5 milliards de dollars selon les estimations de CoinDesk et de Blockaid. Les relevés ne disent pas comment l’attaquant a obtenu, au départ, des signatures du portefeuille de Binance lui-même.
Le débat sur la conception d’Ethereum tourne autour de ce vide. Ido Ben-Natan, directeur général de la société de sécurité Blockaid, a déclaré à Cointelegraph que les fonds auraient pu être volés sans l’EIP-7702. Ivo Georgiev, directeur général du fabricant de portefeuilles Ambire, affirme que les attaquants pouvaient déjà autoriser des transactions. Pour le vol lui-même, les montants et les gels de fonds, lisez notre article de référence sur le piratage de Binance. Ce texte-ci traite d’une seule question : quelle part de l’affaire revient à cette fonctionnalité.
EIP-7702 et piratage de Binance : l’outil d’un seul portefeuille, pas la cause de la perte
Binance chiffre l’impact total à environ 6,3 milliards de dollars et TRM Labs compte 6,36 milliards de dollars, tandis que Blockaid avance plus de 5,5 milliards. Binance 14 était le seul portefeuille délégué, d’après drk.vc, un blog d’analyse. Le pillage qui a fait les gros titres représente donc environ deux cinquièmes du total selon le décompte de TRM, et TRM décrit des transferts signés ordinaires sur les autres blockchains.
Deux chiffres circulent pour Ethereum et ils ne mesurent pas la même chose. CoinDesk parle d’environ 2,5 milliards de dollars sortis d’un portefeuille de Binance en moins de quatre minutes. TRM compte 3,79 milliards de dollars au total sur Ethereum, un chiffre qui englobe aussi les pillages ultérieurs et des portefeuilles qui n’ont jamais été délégués.
EIP-7702, c’est quoi ? Une permission qui ne nomme ni montant ni destinataire
Un compte Ethereum ordinaire, piloté par une clé privée, n’a pas de code. L’EIP-7702 a changé cela quand Pectra est entré en service, le 7 mai 2025. D’après le texte de la proposition, le propriétaire signe un court message qui nomme une blockchain, l’adresse d’un contrat et un nonce, le compteur de transactions du compte. N’importe qui peut ensuite glisser cette signature dans une transaction du nouveau type 4 et payer les frais de gaz. À partir de là, le compte se comporte comme le contrat intelligent désigné.
Les usages prévus sont banals : regrouper plusieurs actions en une seule transaction, ou laisser un tiers régler les frais. Le danger tient à ce que la signature ne dit pas. Elle ne fixe ni destinataire ni montant. Celui qui contrôle le code du contrat délégué contrôle ce que fait le compte, et la délégation reste en place jusqu’à ce que le propriétaire la remplace.
Les auteurs avaient signalé une version plus étroite du risque. Un contrat délégué mal conçu, prévient l’EIP, peut « permettre à un acteur malveillant de prendre un contrôle quasi total du compte EOA d’un signataire », EOA étant le nom technique d’un compte ordinaire piloté par une clé. Un contrat écrit par l’attaquant n’a besoin d’aucune faille.
Deux règles comptent pour la suite. Une autorisation n’est prise en compte que si son nonce est égal au nonce actuel du compte, et une autorisation acceptée l’augmente d’une unité, ce qui empêche de la réutiliser. Un nonce qui ne correspond pas ne fait pas échouer la transaction : l’EIP demande aux nœuds d’ignorer cette autorisation et de passer à la suivante dans la liste. Le propriétaire peut aussi annuler à tout moment en déléguant à l’adresse zéro, ce qui efface le code.
Une transaction, 50 signatures, un seul tir au but
Ces règles expliquent la forme étrange de l’attaque. La transaction du 29 octobre a été envoyée par une adresse de l’attaquant, 0x7C86…5CA0, que Etherscan étiquette « Binance Hot Wallet Exploiter », dans le bloc 26300753. Les 50 autorisations désignaient Binance 14 comme signataire et le même contrat comme délégué. Leurs nonces allaient de 18 914 775 à 18 914 824. Le réseau en a ignoré 49, et la transaction a malgré tout réussi. Celle qui correspondait portait le nonce 18 914 809, soit 34 de plus que la plus basse des hypothèses. La page d’Etherscan cite Blockaid : « Only 1 of 50 was a hit. » (une seule sur 50 a fait mouche)
Pourquoi 50 ? Le nonce d’un portefeuille monte à chaque transaction envoyée, et celui-ci traitait des retraits de clients : une signature préparée à l’avance doit donc deviner où en sera le compteur au moment où elle arrive. Journal du Coin rapporte que l’attaquant ne connaissait pas le nonce en cours. TRM Labs va plus loin : ce lot « suggère que l’accès était peut-être limité dans le temps », ou que les signatures devaient être demandées « via un système ». C’est une évaluation. Le fait qui la sous-tend est plus simple : 50 signatures pour Binance 14 existaient avant 20 h 20 min 59 s UTC.
Le contrat était prêt bien avant. Blockaid, dans un rapport résumé par TechFlow, et CoinDesk situent tous deux son déploiement vers 16 h UTC, plus de quatre heures plus tôt. Son code source n’est pas publié sur Etherscan. Drk.vc affirme que le code exige que l’appelant soit l’adresse même de l’attaquant, et CoinDesk décrit lui aussi un contrat que seul ce portefeuille pouvait manœuvrer.
De la délégation à la révocation : 3 heures 50 d’accès ouvert
Le premier pillage montre ce que la délégation a rapporté. L’attaquant a appelé une fonction nommée sweep sur Binance 14 lui-même, avec une valeur nulle, et a payé 0,000413776 ETH de frais, moins d’un dollar. Sont sortis 167 464,2479 ETH et 63 jetons, dont environ 1,615 milliard d’USDT. Aucune nouvelle signature de Binance n’était nécessaire.
Comme la délégation est restée en place, les dépôts arrivés sur Binance 14 après le premier pillage ont été pris eux aussi. Le portefeuille était par ailleurs opérateur d’un portefeuille de conservation intelligent que CoinDesk et Blockaid appellent Hot Wallet 34 : des appels passés par son intermédiaire ont donc déplacé aussi de l’USDC.
| Heure (UTC) | Événement | Source |
|---|---|---|
| 29 oct., vers 16 h 00 | Déploiement du contrat de pillage | Blockaid via TechFlow, CoinDesk |
| 29 oct., 20 h 20 min 59 s | Délégation : 50 autorisations, une seule valide | Etherscan |
| 29 oct., 20 h 24 min 23 s | Premier pillage de Binance 14, 3 min 24 s plus tard | Etherscan, TRM |
| 29 oct., 20 h 41 min 23 s | 780 millions d’USDC déplacés via Hot Wallet 34 ; 43 millions de plus ensuite | Blockaid via TechFlow |
| 29 oct., de 20 h 41 à 23 h 56 | Pillages suivants à 20 h 41, 20 h 59, 21 h 04, 21 h 44, 22 h 39 et 23 h 56 | TRM |
| 30 oct., 00 h 10 min 35 s | Binance 14 révoque la délégation vers l’adresse zéro | Etherscan |
La révocation est une transaction de type 4 que Binance 14 s’est envoyée à lui-même, avec une autorisation valide pointant vers l’adresse zéro. Le portefeuille étant l’expéditeur, la signature vient de sa propre clé. Cela laisse penser que Binance avait repris la main sur sa signature à 00 h 10 UTC, environ 3 heures 50 après la délégation, même si Binance ne l’a pas dit dans les sources que nous avons lues.
Le reste de la perte n’a pas eu besoin de l’EIP-7702
Le meilleur argument des sceptiques vient de la même soirée. Vingt-quatre secondes après le premier pillage, Binance 16, qui n’a jamais été délégué, a signé un transfert de 28 005,6 ETH et d’environ 108 millions de dollars de jetons, selon drk.vc. Sur Bitcoin, Tron, le XRP Ledger et Solana, les fonds sont partis dans des transferts signés ordinaires, rapportent CoinDesk et drk.vc.
L’attaquant pouvait donc obtenir des signatures sur Ethereum avec ou sans EIP-7702, et sur des blockchains qui n’ont pas cette fonctionnalité, comme Bitcoin. Pourquoi elle n’a servi que sur un seul portefeuille reste inexpliqué.
Clé volée ou système de signature détourné : les versions s’opposent
C’est ici que la blockchain cesse d’aider. Chacune des explications ci-dessous colle aux transactions, et aucune n’a été prouvée publiquement.
| Qui | Ce qu’ils disent | Statut |
|---|---|---|
| Binance | La première enquête « may involve a compromised DevOps engineer’s laptop » (pourrait impliquer l’ordinateur portable compromis d’un ingénieur DevOps) ; « no evidence of any wallet private key leak » (aucune preuve de fuite de clé privée de portefeuille) ; d’autres points de brèche ont été trouvés depuis, sans être nommés | Version de l’entreprise, non vérifiée de façon indépendante |
| Blockaid | Son message, intégré par crypto.news : « an attacker used a stolen key to drain $5.5B » (un attaquant a utilisé une clé volée pour vider 5,5 milliards de dollars) ; son rapport indique que la fuite de clé et le mécanisme 7702 ont été confirmés en 11 minutes, selon TechFlow | Affirmation d’un éditeur, sans preuve publique |
| TRM Labs | L’explication la plus probable est que l’attaquant pouvait faire que « le système de signature du portefeuille chaud de Binance signe les transactions de son choix sur toutes les blockchains » | Évaluation, présentée comme telle |
| drk.vc | Quelqu’un qui détiendrait la clé brute aurait pu envoyer directement des transferts ; le blog en déduit un accès au circuit de signature. Il cite SlowMist, selon qui une fuite de clé « may be involved » (pourrait être en cause) | Déduction d’un analyste |
Le raisonnement de TRM est le plus détaillé de ceux qui sont proposés. smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">Il relève des signatures valides sur des blockchains, des types de clés et des schémas de signature différents en une demi-heure environ, ce qu’une attaque d’hameçonnage visant un seul signataire Ethereum n’expliquerait pas. Le co-directeur général Richard Teng a ajouté sur X, selon CoinDesk : « L’attaquant n’a pas simplement utilisé les droits d’un ingénieur, et il ne s’agissait pas d’une seule action en un clic. »
Mises côte à côte, la formule de Binance (« aucune preuve ») et celle de Blockaid (« clé volée ») ne s’accordent pas, même si crypto.news, qui rapporte les deux, n’essaie pas de les concilier. Selon Journal du Coin, Ben-Natan lui-même parle d’un usage détourné de la clé et non d’un vol. Ce genre de querelle n’est pas nouveau : cette semaine, l’affaire du robot de trading Bloom opposait déjà « aucune clé divulguée » à des portefeuilles qui avaient chacun signé leur propre vidage. Pour comprendre pourquoi la distinction compte, notre guide sur les clés privées et publiques donne les bases.
Ce que disent Ben-Natan, Georgiev et VEER de l’EIP-7702
Trois voix nommées portent le débat pour l’instant, toutes dans l’article de Helen Partz publié par Cointelegraph le 30 octobre.
Pour Ben-Natan, l’argent aurait pu être volé sans la fonctionnalité. « The 7702 upgrade is a way to do this in one sweep and maybe a way to bypass some sort of checks they may have » (la mise à jour 7702 est un moyen de le faire d’un seul coup, et peut-être de contourner certains contrôles qu’ils pouvaient avoir), a-t-il dit au média. Sans elle, estime-t-il, les attaquants auraient eu besoin de plusieurs transactions. Il pense qu’un ordinateur de développeur compromis a pu donner accès à l’infrastructure de signature et que le signataire a « signé une transaction qu’il n’aurait pas dû signer ». Il a averti que d’autres plateformes d’échange s’exposent au même type d’attaque sur leurs systèmes de signature, et que la simulation des transactions pourrait repérer les demandes malveillantes avant leur validation.
Pour Georgiev, la fonctionnalité a changé peu de choses, puisque les attaquants pouvaient déjà autoriser des transactions et auraient pu vider les fonds par d’autres moyens. « This is a problem with EIP 7702, it’s just very very poorly understood » (c’est un problème lié à l’EIP 7702, mais il est très, très mal compris), a-t-il déclaré. Son inquiétude pratique : les ingénieurs d’une plateforme qui reprennent le contrôle d’un portefeuille pourraient oublier de révoquer une délégation malveillante.
VEER, que Cointelegraph présente seulement comme un membre de la communauté Ethereum, a rappelé des avertissements formulés lors des discussions de 2024 sur la proposition. VEER juge aussi que l’attaque semblait plus large qu’une seule signature malveillante, mais que la fonctionnalité a offert aux attaquants « a handy sweep button on Ethereum » (un bouton de pillage bien pratique sur Ethereum).
Cointelegraph résume la situation ainsi : l’EIP-7702 n’a pas causé le piratage mais l’a peut-être amplifié, et cette formule est celle du média. Ce qui suit est la lecture de Coindaro, qui n’est ni un constat ni une accusation. La remarque de Ben-Natan sur le contournement de contrôles soulève une question : si une analyse post-mortem montrait que les règles de Binance auraient bloqué des retraits ordinaires mais laissé passer une autorisation de type 4, la fonctionnalité passerait du statut de commodité à quelque chose de plus proche d’une cause. Rien de ce qui a été publié ne montre que ces règles fonctionnaient ainsi, et nous ne disons pas qu’elles fonctionnaient ainsi.
Les abus de l’EIP-7702 avant Binance : contrats de pillage et petites pertes
Le schéma est plus ancien que ce piratage, à une tout autre échelle. Le 30 mai 2025, trois semaines après Pectra, Wintermute a écrit sur X que « over 97% of all EIP-7702 delegations were authorized to multiple contracts using the same exact code » (plus de 97 % des délégations EIP-7702 étaient autorisées vers plusieurs contrats utilisant exactement le même code), des contrats qu’elle décrivait comme des programmes de pillage. Ces mots figurent dans l’article de CoinDesk et dans d’autres comptes rendus. Deux chiffres circulent : le texte propre de CoinDesk et un résumé de Bitget News parlent de plus de 80 % de délégations vers des contrats copiés, et les 97 % sont ceux du message de Wintermute. Nous n’avons pas pu ouvrir le message lui-même. La société écrivait : « The CrimeEnjoyor contract is short, simple, and widely reused. » (Le contrat CrimeEnjoyor est court, simple et largement réutilisé.)
Taylor Monahan, chercheuse en sécurité, disait alors que le problème de fond était la faible protection des clés privées, et SlowMist, fondée par Yu Xian, conseillait aux portefeuilles d’afficher clairement le contrat de destination quand un utilisateur signe une délégation. Scam Sniffer a signalé en mai 2025 qu’un portefeuille avait perdu environ 146 551 dollars dans un lot de transactions malveillantes, que SlowMist a rattaché à Inferno Drainer. Cointelegraph rappelle aussi que des détenteurs de World Liberty Financial ont déclaré des pertes liées à des délégations malveillantes en septembre 2025.
Blockaid recense quatre incidents liés à l’EIP-7702 au premier semestre 2026, pour environ 1,08 million de dollars au total. Le seul premier pillage de Binance 14 représente plus de 2 000 fois cette somme. Bybit, le précédent record à environ 1,5 milliard de dollars en février 2025, date d’avant Pectra, si bien que la fonctionnalité n’y a joué aucun rôle : ses attaquants avaient compromis une interface de signature.
Révoquer une délégation, protéger les plateformes : ce qui peut changer
La plupart des propositions visent le moment qui précède la signature, et elles viennent de gens qui ont un intérêt dans l’affaire. Blockaid vend ce type de protection, et ses conseils se lisent en le gardant à l’esprit. L’entreprise veut que chaque transaction, y compris les listes d’autorisations 7702, soit simulée et examinée au regard de listes blanches et de plafonds avant la signature, puis rejetée même si les approbateurs ont donné leur accord. Elle réclame aussi une surveillance qui signale un portefeuille chaud qui acquiert soudain du code, avec des déplacements de fonds ou des révocations automatiques en réponse. Elle ajoute que les portefeuilles devraient avoir des transactions de révocation préparées à l’avance, et affirme avoir émis des alertes 1 minute 55 secondes après le premier pillage.
- Journal du Coin énumère trois garde-fous : bloquer les transactions de type 4 depuis les portefeuilles chauds de retrait, n’autoriser que des contrats délégués approuvés, et simuler avant de signer.
- Le conseil de SlowMist en 2025 vaut pour les portefeuilles grand public : afficher le contrat délégué avant que l’utilisateur ne signe.
- L’avertissement de Georgiev vaut après n’importe quel incident : chercher les délégations et les révoquer, comme Binance 14 l’a fait à 00 h 10 min 35 s UTC.
Pour qui détient un portefeuille personnel, la même logique s’applique à plus petite échelle. Une demande de délégation ressemble davantage à la remise d’un compte qu’à la validation d’un paiement, puisqu’elle ne nomme ni somme ni destinataire. Pour en supprimer une, le propriétaire du compte délègue à l’adresse zéro, la méthode que définit l’EIP et celle qu’a employée Binance 14.
Ce que l’on ignore encore de l’attaque par EIP-7702
Binance a promis une analyse post-mortem et une preuve de réserves actualisée, sans date pour l’une ni pour l’autre. Tant que ce post-mortem n’est pas publié, ces points restent ouverts :
- Comment les 50 signatures ont été produites : un ordinateur portable, un service de signature ou une clé.
- Si une clé a vraiment fuité, entre le « no evidence » de Binance, la clé volée de Blockaid et le système de signature de TRM.
- Pourquoi Ethereum a été la seule blockchain avec une délégation, et seulement sur Binance 14.
- Si d’autres plateformes ont des délégations sur leurs portefeuilles chauds, faute de balayage publié que nous ayons trouvé.
- Ce qu’en pensent les développeurs d’Ethereum : nous n’avons trouvé aucune déclaration d’un développeur du cœur du protocole, de Vitalik Buterin ou de l’Ethereum Foundation dans les sources consultées à la mi-journée du 30 octobre.